12:32 a.m.
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
2:11 a.m.
New subject: [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..
2:37 a.m.
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
5:40 a.m.
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
5139
days inactive
5139
days old
3 comments
4 participants
participants (4)
-
John Doyle -
Paul Nittel -
Ramesh Reddy -
Steven Hawkins