[teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell

[Larry O'Leary]

On Mon, 2010-04-12 at 17:22 -0400, Steven Hawkins wrote:
> Eliminating C. is the difference between offering a scripting language with hooks vs. a "query tool".  That's probably worth exploring more.  I would say that there are 3 distinctly different tools we were trying to satisfy with AdminShell:
> 
> T1. an interactive/scriptable administrative console
> T2. an interactive/scriptable query tool
> T3. an scriptable test tool for both 1 and 2.
> 
> Arguably we were the only ones interested in T3, and as mentioned in the last email that functionality can be ported over quite easily regardless.
> For T1 the difference between the Groovy solution and the BeanShell solution is minimal (function syntax is the same, java can be imported and called in the same ways, etc.) and the Groovy solution can be changed to be contextual as well - although it is worth noting that our context is more complicated than before since your admin and sql connections are separate, which is not yet reflected in the old adminshell prompt.  So to perform admin logic you don't need to be any more of a Java developer than you did with the BeanShell based tooling.
> 
> For me the only real difference comes down to T2.  From a technical perspective, the manner in which we extend the host grammar to support T2 is brittle and has limitations such as multiline handling or leading comments, etc. that are not handled by our hook.  Even with those limitations I understand that it does serve as a reasonable approximation to something like SQL*Plus.  I question whether we need to support specialized tooling for this purpose (over just using what's available in Groovy).  We could just as well promote the use of http://sourceforge.net/projects/sqlshell/ or the older http://henplus.sourceforge.net/.

The original intention of the AdminShell was to give an administrator a
simple means of checking state/services within a server.  It was a
replacement and great improvement to the old svcmgr.  The idea was that
a user could execute the shell in interactive mode or non-interactive
mode and execute state and admin commands against the server.  

Honestly, I am not sure where the SQL / query-execution came into play.
Seems like AdminShell was a bad place for this in the first place.  This
should have lived in QueryShell or JDBCiSQL... oh wait!  

So, as for the SQL / query-execution we should basically forget about
it.  If a user wants to execute SQL, then they can write a Java
application to do so... or better yet, use one of the many
third-party/OSS solutions that allow a person to execute a query against
a JDBC data-source... I wonder if Eclipse has such a tool.

As for the AdminShell's administrative functions, as long as we provide
an out-of-the-box list of pre-defined or wrapped API commands to do
common tasks, it will suffice.  From looking at your example, it appears
that nothing has really changed but I would like to see it simplified
further:

connect(user, passwd)
exportConnectionFactory("TPCR_S2k", "test.xml")
...


Basically, adminConn would implicitly contain the reference to the
connection if one was not given.  For example:

myConn = connect(user, passwd)
exportConnectionFactory("TPCR_S2k", "test.xml")
... 

Would result in an error because adminConn is still NULL.  

However, 
myConn = connect(user, passwd)
myConn.exportConnectionFactory("TPCR_S2k", "test.xml")
...

Would work just fine.


> ----- Original Message -----
> From: "Paul Nittel" <pnittel at redhat.com>
> To: "Steven Hawkins" <shawkins at redhat.com>
> Cc: "teiid-users" <teiid-users at lists.jboss.org>, "teiid-dev" <teiid-dev at lists.jboss.org>
> Sent: Monday, April 12, 2010 12:37:21 PM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-dev] Alternative scripting envrionment for AdminShell
> 
> 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 at redhat.com>
> To: "teiid-users" <teiid-users at lists.jboss.org>, "teiid-dev" <teiid-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
> _______________________________________________
> teiid-users mailing list
> teiid-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-users

--

Larry O'Leary
Middleware Support Engineering Group
Global Support Services
Red Hat, Inc.
loleary at redhat.com
1.866.LINUX70 (+1.314.336.2990) xt 81-62909
Office: +1.314.336.2909
Mobile: +1.618.420.7623
--
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/