Re: [teiid-users] Alternative scripting envrionment for AdminShell
by Steven Hawkins
JUnit integration would not be lost. The integration now (basically just a static import of the Assert methods) can be ported exactly, and the result set logic can be ported as well.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(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>
Sent: Monday, April 12, 2010 12:11:40 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-users] Alternative scripting envrionment for AdminShell
D. JUnit integration and assertion logic on the result sets.
I have NO preference in using the Groovy vs Bean shell. I am OK with
Teiid using groovy. Groovy definitely seems to have mind share these
days and have better tools and support. Command history and GUI tools
are very valuable. Support of closures is nice.
On Mon, 2010-04-12 at 11:32 -0400, Steven Hawkins wrote:
> I would propose that we would need to drop support for C completely,
> since it requires both the notion of a contextual connection and
> extending the host grammar (which cannot be done without deep hooks).
>
IMO, A,B,C,D are the value add features that Admin Shell has, especially
in the interactive mode. If we remove these features, it is basically a
java code interpreter and will make users to learn the groovy
syntax/libraries before they can use it.
With out any contextual information any scripting tool is use less IMO.
"it" variable from your code sample is an example of contextual
information support in groovy. Is there way add additional variables to
the groovy environment (with out deep hooks I mean)?
I myself, do not mind doing in the new way, but not sure if I am going
to like all the verbose typing now I have to do to use this as a query
tool.
Ramesh..
14 years, 5 months
Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell
by John Doyle
I really appreciate the ability to quickly connect to the VDB with the existing tool and just throw some SQL at the connection. I would prefer to keep C as well and avoid the verbosity of the groovy example.
~jd
----- "Paul Nittel" <pnittel(a)redhat.com> wrote:
> A good thing about AdminShell and its predecessors, is the user
> needn't be Java developer to use it. If you eliminate 'C', aren't we
> doing a disservice to our users?
>
> Cheers,
> -------
> Paul Nittel
> JBoss Sr. Quality Assurance Engineer
> Red Hat, Inc.
> 314-336-2907 (81-62907)
>
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>
>
> ----- Original Message -----
> From: "Steven Hawkins" <shawkins(a)redhat.com>
> To: "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev"
> <teiid-dev(a)lists.jboss.org>
> Sent: Monday, April 12, 2010 10:32:12 AM GMT -06:00 US/Canada Central
> Subject: [teiid-dev] Alternative scripting envrionment for AdminShell
>
> Hello all,
>
> Before we get to a 7.0 RC, I would like to propose replacing our
> BeanShell based Adminshell with one based upon Groovy. The rationale
> for this change is:
> 1. BeanShell is no longer maintained
> 2. BeanShell interactive and graphical tools have usability issues
> (for example script development with AdminShell typically involves
> opening a separate text editor)
> 3. We have deep hooks into the scripting language for the admin shell
> that are difficult to maintain.
>
> While we could stay with BeanShell and address 2/3 it does not seem
> worth the effort given that we have the opportunity of a major release
> to make major changes. If we fully reduce our hooks into the
> scripting language/shell (which would move all relevant logic into
> Java), then the things we could loose are:
>
> A. A help system based upon the script source
> B. A contextual (where the connection context is shown on the prompt)
> command system
> C. Grammar extension for SQL, such that just entering a SQL is all
> that is required for execution.
>
> The things we would immediately gain with Groovy are:
>
> A command line shell that has a command history, maintains an editable
> buffer, and supports built-in script recording.
> A graphical console that functions as a simple text editor based IDE
> (with syntax highlighting) and supports full script and selected text
> execution.
> Built-in support for simplifying JDBC execution (which is extensible
> to support getting our debug logs, query plans, etc.), see
> http://groovy.codehaus.org/Tutorial+6+-+Groovy+SQL.
> And a wealth of other built-in Groovy modules for common activities,
> such as XML handling.
>
> To address A we would want to expose our relevant JavaDocs via help
> extensions in both the command line and graphical tools.
> I would argue that it's a matter of developer preference as to whether
> we address B. See the below example scipts.
>
> Example Groovy script:
>
> import static org.teiid.adminshell.AdminShell.* //optional - we could
> just as easily add this into the shell context automatically
>
> admin = connectAsAdmin()
>
> admin.exportConnectionFactory("TPCR_S2k", "test.xml")
>
> sql = connect()
>
> sql.eachRow("select * from tables", { println it })
>
>
>
> Current AdminShell script:
>
> connectAsAdmin();
>
> exportConnectionFactory("TPCR_S2k", "test.xml");
>
> connect();
>
> select * from tables;
>
> printResultSet();
>
>
> With the Groovy script (note ending ; are optional) explicit admin and
> sql objects are used to represent their respective connections. If
> additional connections are needed, then additional variables are
> introduced. In AdminShell the current connection is contextually
> bound so that functions may be called without explicitly identifying
> which connection is used. The same logic could be introduced in the
> Groovy hooks by providing static hooks to all the methods available on
> the Admin and Sql objects.
>
> I would propose that we would need to drop support for C completely,
> since it requires both the notion of a contextual connection and
> extending the host grammar (which cannot be done without deep hooks).
>
> Any thoughts?
>
> Steve
>
> _______________________________________________
> 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
14 years, 5 months
Alternative scripting envrionment for AdminShell
by Steven Hawkins
Hello all,
Before we get to a 7.0 RC, I would like to propose replacing our BeanShell based Adminshell with one based upon Groovy. The rationale for this change is:
1. BeanShell is no longer maintained
2. BeanShell interactive and graphical tools have usability issues (for example script development with AdminShell typically involves opening a separate text editor)
3. We have deep hooks into the scripting language for the admin shell that are difficult to maintain.
While we could stay with BeanShell and address 2/3 it does not seem worth the effort given that we have the opportunity of a major release to make major changes. If we fully reduce our hooks into the scripting language/shell (which would move all relevant logic into Java), then the things we could loose are:
A. A help system based upon the script source
B. A contextual (where the connection context is shown on the prompt) command system
C. Grammar extension for SQL, such that just entering a SQL is all that is required for execution.
The things we would immediately gain with Groovy are:
A command line shell that has a command history, maintains an editable buffer, and supports built-in script recording.
A graphical console that functions as a simple text editor based IDE (with syntax highlighting) and supports full script and selected text execution.
Built-in support for simplifying JDBC execution (which is extensible to support getting our debug logs, query plans, etc.), see http://groovy.codehaus.org/Tutorial+6+-+Groovy+SQL.
And a wealth of other built-in Groovy modules for common activities, such as XML handling.
To address A we would want to expose our relevant JavaDocs via help extensions in both the command line and graphical tools.
I would argue that it's a matter of developer preference as to whether we address B. See the below example scipts.
Example Groovy script:
import static org.teiid.adminshell.AdminShell.* //optional - we could just as easily add this into the shell context automatically
admin = connectAsAdmin()
admin.exportConnectionFactory("TPCR_S2k", "test.xml")
sql = connect()
sql.eachRow("select * from tables", { println it })
Current AdminShell script:
connectAsAdmin();
exportConnectionFactory("TPCR_S2k", "test.xml");
connect();
select * from tables;
printResultSet();
With the Groovy script (note ending ; are optional) explicit admin and sql objects are used to represent their respective connections. If additional connections are needed, then additional variables are introduced. In AdminShell the current connection is contextually bound so that functions may be called without explicitly identifying which connection is used. The same logic could be introduced in the Groovy hooks by providing static hooks to all the methods available on the Admin and Sql objects.
I would propose that we would need to drop support for C completely, since it requires both the notion of a contextual connection and extending the host grammar (which cannot be done without deep hooks).
Any thoughts?
Steve
14 years, 5 months
Re: [teiid-users] [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
14 years, 5 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
14 years, 5 months
version 7.0 stand alone server configuration
by Charles Simon
I have been developing an connector with version 6.2 and realized I
should be looking forward to version 7.0 so I download some files from
7.0 and started reading up on the changes coming in 7.
While reading the "Teiid 7.0 Installation Guide" I read the following:
> Teiid 7.0 installation is entirely different from the previous
> versions. Previously Teiid could
> be installed as standalone server or embedded server. Starting with
> this release Teiid will
> need to be installed into a existing JBoss AS installation. Teiid will
> be another component
> inside the JBoss AS rather than have its own runtime environment. One
> disadvantage of this
> configuration is Teiid will not support the "embedded" mode in 7.0
> version.
I was shocked to find that Teiid will no longer support a stand alone
server installation and must be installed into a JBoss AS environment.
Am I wrong?
--
Charles Simon
Principal Software Engineer
Select Business Solutions, Inc.
35 Nutmeg Drive
Trumbull, CT 06611
http://www.selectbs.com
mailto:charles.simon@selectbs.com
14 years, 5 months
Re: [teiid-users] version 7.0 stand alone server configuration
by Ramesh Reddy
On Mon, 2010-04-05 at 16:08 -0500, Van Halbert wrote:
> Isn't the embedded container option coming out later this year? Therefore, the standalone option will be returning in this manner at a later date.
>
With JBoss AS 6.0 there is supposed to be support for the Embedded JBoss
version. When Teiid adapts to JBoss 6.0 it can support the Embedded
Teiid. Once "Embedded Teiid" is available, the idea is to embed it in
any java application. Currently Teiid only supports JBoss AS 5.1.0, so
no "embedded".
Right now with 7.0 Teiid, "embedded" means not creating JDBC connection
over the socket. You can create a Data Source to your VDB using the
Teiid's Embedded Driver, however this option is limited to work only
JBoss AS.
Ramesh..
14 years, 5 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..
14 years, 5 months