[teiid-dev] Alternative scripting envrionment for AdminShell

[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 at 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 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-dev mailing list
> teiid-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev