possible milestone
by Steven Hawkins
Now that last nights errors have been cleaned up, are there any more hold ups for a milestone?
Steve
15 years, 11 months
Re: [teiid-dev] query plan changes
by Steven Hawkins
Yes the defaults are both off. The SET command is scoped to the session and currently has the same affect as changing the connection or datasource properties. Using NOEXEC is the same as Sybase and SQLServer, which also use the EXEC syntax for calling procedures. We can of course make it whatever we want.
----- Original Message -----
From: "Ken Johnson" <kejohnso(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>, "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Tuesday, April 6, 2010 2:10:59 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] query plan changes
Steven Hawkins wrote:
> Hello all,
>
> Currently we have OPTION SHOWPLAN PLANONLY DEBUG to control planning and execution. The drawbacks are that this introduces three reserved words (SHOWPLAN, PLANONLY, DEBUG) and it's only applicable to the top level user query.
>
> The proposed replacement makes use of https://jira.jboss.org/jira/browse/TEIID-906, which added basic support for a set statement:
>
> SET SHOWPLAN [ON|DEBUG|OFF]
> SET NOEXEC [ON|OFF] - general replacement for PLANONLY, will not execute the command if ON
>
This seems a reasonable way to reduce the keywords and allow repetitive
executions without having to modify the query syntax each time. How are
these commands scoped, per session? It would be cool if these could be
used to enable plan output for a query coming from an application where
the user cannot easily change the query itself. Presumably defaults
would be SHOWPLAN=OFF and NOEXEC=OFF.
Given that EXEC is a reserved word for executing a procedure, do you
think NOEXEC might cause confusion (users thinking it's the negative
form of EXEC)?
> I would also like to remove most of the logic surrounding the org.teiid.client.plan.PlanNode class. The visitors, display helpers, etc. Since we don't publish a meaningful schema for the xml form(s) or document the property keys we might as well assume that we're the primary consumers and forgo the flexibility.
>
Don't know about this one. Hard to foresee how users might consume the
query plan XML in the future.
> Any thoughts?
>
> Steve
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
>
--
Ken Johnson
Sr. Product Manager
JBoss Middleware Business Unit
Red Hat, Inc
978.392.3917
ken.johnson(a)redhat.com
15 years, 11 months
query plan changes
by Steven Hawkins
Hello all,
Currently we have OPTION SHOWPLAN PLANONLY DEBUG to control planning and execution. The drawbacks are that this introduces three reserved words (SHOWPLAN, PLANONLY, DEBUG) and it's only applicable to the top level user query.
The proposed replacement makes use of https://jira.jboss.org/jira/browse/TEIID-906, which added basic support for a set statement:
SET SHOWPLAN [ON|DEBUG|OFF]
SET NOEXEC [ON|OFF] - general replacement for PLANONLY, will not execute the command if ON
I would also like to remove most of the logic surrounding the org.teiid.client.plan.PlanNode class. The visitors, display helpers, etc. Since we don't publish a meaningful schema for the xml form(s) or document the property keys we might as well assume that we're the primary consumers and forgo the flexibility.
Any thoughts?
Steve
15 years, 11 months
Re: [teiid-dev] Change in nomenclature of "Connector Binding" to "Connection Factory"
by Ted Jones
Ramesh,
What about connector property references (e.g. Connector Batch Size)? There may be others, but that is the only one I reference in my plugin.
Thanks,
Ted
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: teiid-dev(a)lists.jboss.org
Sent: Monday, April 5, 2010 2:35:59 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Change in nomenclature of "Connector Binding" to "Connection Factory"
The following are the related Admin API Changes with this name change
assignBindingToModel ==> assignConnectionFactoryToModel
setConnectorBindingProperty ==> setConnectionFactoryProperty
addConnectorType ==> addConnector
deleteConnectorType ==> deleteConnector
exportConnectorType ==> exportConnector
addConnectorBinding ==> addConnectionFactory
deleteConnectorBinding ==> deleteConnectionFactory
exportConnectorBinding ==> exportConnectionFactory
getConnectorTypes ==> getConnectorNames
getConnectorBindings ==> getConnectionFactories
getConnectorBinding ==> getConnectionFactory
getConnectorBindingsInVDB ==> getConnectionFactoriesInVDB
getConnectorConnectionPoolStats ==> getConnectionFactoryStats
getConnectorTypePropertyDefinitions ==> getConnectorPropertyDefinitions
startConnectorBinding ==> startConnectionFactory
stopConnectorBinding ==> stopConnectionFactory
and class ConnectorBinding ==> ConnectionFactory in admin api.
Ramesh..
On Mon, 2010-04-05 at 11:07 -0500, Ramesh Reddy wrote:
> On Mon, 2010-04-05 at 11:02 -0500, John Verhaeg wrote:
> > On Apr 5, 2010, at 10:44 AM, Ramesh Reddy wrote:
> >
> > > Here are some comparisons
> > > ---------------------------------------------------------------------
> > > 6.2 | 7.0
> > > ---------------------------------------------------------------------
> > >
> > > Connector Type | RAR File (JCA Connector)
> > > ---------------------------------------------------------------------
> > > Connector Binding | Connection Factory
> > > ---------------------------------------------------------------------
> >
> >
> > I'd still say the existence of a RAR file "backing" the concept of a connector is not something we want to put in front of the user. I'd want to call what we used to call a "Connector Type" simply a "Connector" (meaning JCA connector).
>
> +1
> Agree, I see that already.
>
> Ramesh..
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
15 years, 11 months
Change in nomenclature of "Connector Binding" to "Connection Factory"
by Ramesh Reddy
With the JCA changes several users complained about the nomenclature
that is still in use in Teiid about Connector Bindings. A Connector
Binding in Teiid is a connection pool/factory to source systems that
contain the data that are integrated using Teiid.
In the Container environment the components that provide the connections
to the sources are called "Connection Factory". If the connection is to
a RDBMS they are called "Data Sources".
With JCA changes, Connectors are now JCA connectors. To keep up with
same lingo as Containers, we are proposing that we change the
nomenclature of Teiid's "Connector Binding" to "Connection Factory".
All the external APIs, documents and web pages will be modified for
accommodate this change. Although, APIs will be modified immediately for
7.0 release the documents and web will be modified as time allows for
7.0 release. I logged https://jira.jboss.org/jira/browse/TEIID-1032
Here are some comparisons
---------------------------------------------------------------------
6.2 | 7.0
---------------------------------------------------------------------
Connector Type | RAR File (JCA Connector)
---------------------------------------------------------------------
Connector Binding | Connection Factory
---------------------------------------------------------------------
One difference from previous versions of Teiid is, if the Connector
binding was to a RDBMS, a single Connector binding represented the
connection between the source system (ex:oracle) and Teiid translation
layer. In 7.0, the translation layer and source connection are
independent. The translation layer is now called "Connection Factory"
and source connection to RDBMS is called "Data Source", and Connection
Factory will have reference to the Data Source for making the data
request calls. I will be writing blog soon on this topic if you are
interested.
Comments?
Thanks
Ramesh..
15 years, 11 months
Re: [teiid-dev] Need to Document Alternate Means of Achieving Web Services and XML Usage (TEIID-673)
by Ted Jones
The REST example has been published and reflected as such in the appropriate Jira. With regards to top-down/bottom-up web services, we are using CXF and the existing web service models in 7.0. I suppose we could create a new Jira for that puruit and close the documentation Jira's.
The XML Jira's can be closed since we have decided to keep existing functionality. We still need to reflect the fact that an alternative solution should be pursued for the XML Document story though.
Thanks,
Ted
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: teiid-dev(a)lists.jboss.org
Sent: Thursday, April 1, 2010 4:58:51 PM GMT -06:00 US/Canada Central
Subject: [teiid-dev] Need to Document Alternate Means of Achieving Web Services and XML Usage (TEIID-673)
JPAV, Ted,
We are trying to clean-up JIRAs that are still targeted to the 7.0 and I
came across few JIRAs related to Web Service stuff.
I know, you both have done work in this area, can we publish your
findings in community wiki, so that we can close these JIRAs?
Any further work on this with regards to tooling, we will do in separate
JIRAs at later time. If we are not pursuing some scenarios at all, then
we can mark them as such too. Please take a look at them here
https://jira.jboss.org/jira/browse/TEIID-673
My another intention is to further refine these scenarios through
community help.
Thanks.
Ramesh..
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
15 years, 11 months
Need to Document Alternate Means of Achieving Web Services and XML Usage (TEIID-673)
by Ramesh Reddy
JPAV, Ted,
We are trying to clean-up JIRAs that are still targeted to the 7.0 and I
came across few JIRAs related to Web Service stuff.
I know, you both have done work in this area, can we publish your
findings in community wiki, so that we can close these JIRAs?
Any further work on this with regards to tooling, we will do in separate
JIRAs at later time. If we are not pursuing some scenarios at all, then
we can mark them as such too. Please take a look at them here
https://jira.jboss.org/jira/browse/TEIID-673
My another intention is to further refine these scenarios through
community help.
Thanks.
Ramesh..
15 years, 11 months