So one possible approach is: - provide a Groovy based AdminShell for admin scripting, but document how the classes can be used in you JVM scripting language of choice. It can retain our contextual admin logic, and while SQL execution via Groovy (not through parser interception) would be possible in these scripts, it would not be a primary function of the tool. - promote the use of SQuirreL/Execute Query/etc. for graphical and Henplus/SQLShell/etc. for a command line SQL tool

So one possible approach is: - provide a Groovy based AdminShell for admin scripting, but document how the classes can be used in you JVM scripting language of choice. It can retain our contextual admin logic, and while SQL execution via Groovy (not through parser interception) would be possible in these scripts, it would not be a primary function of the tool. - promote the use of SQuirreL/Execute Query/etc. for graphical and Henplus/SQLShell/etc. for a command line SQL tool

----- Original Message ----- From: "Ken Johnson" <kejohnso(a)redhat.com&gt; To: "Steven Hawkins" <shawkins(a)redhat.com&gt; Cc: rareddy(a)redhat.com, "teiid-users" <teiid-users(a)lists.jboss.org&gt;, "teiid-dev" <teiid-dev(a)lists.jboss.org&gt; Sent: Tuesday, April 13, 2010 4:15:41 PM GMT -06:00 US/Canada Central Subject: Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell Steven Hawkins wrote: > It doesn't seem like we have yet reached a consensus, but it does seem like: > 1. people do like having a SQL oriented interactive command line tool. > 2. most see the SQL functionality as separable from the admin/test. > > Agreed? > > I'd also like to relay a local discussion with Ramesh. His basic premise was that if we decouple the admin/test aspects and promote an alternative command line SQL tool, then we should just forgo offering any built-in environment for administrative scripting. In this case the approach would be to just document which class/classes could be imported (as shown in the previous Groovy example with the static import of AdminShell methods) into your java scripting language of choice. > > I think this falls short on "out-of-the-box" experience. I like the idea of a Groovy-based shell for Admin and a separate utility for ad-hoc SQL without the user being required to configure their environment. Of course, it would be nice if we *also* provided the option to import/extend your java scripting environment of choice. > ----- Original Message ----- > From: "Ramesh Reddy" <rareddy(a)redhat.com&gt; > To: "John Doyle" <jdoyle(a)redhat.com&gt; > Cc: "Steven Hawkins" <shawkins(a)redhat.com&gt;, "teiid-users" <teiid-users(a)lists.jboss.org&gt;, "teiid-dev" <teiid-dev(a)lists.jboss.org&gt;, "Paul Nittel" <pnittel(a)redhat.com&gt; > Sent: Tuesday, April 13, 2010 9:41:49 AM GMT -06:00 US/Canada Central > Subject: Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell > > On Tue, 2010-04-13 at 09:27 -0400, John Doyle wrote: > > >> You nailed my concern Steve. I've never actually used AdminShell for >> admin tasks, I use it like >> SQL*PLUS. I think there are probably more reasons to separate these >> concerns than to combine them. I haven't looked at either of the two >> tools you linked to, but if we can validate that one of them works >> well enough then I think that should be sufficient for a query tool >> for Teiid. >> >> I think the added verbosity of the groovy solution is more acceptable >> for an admin tool than for a query tool, and is worth it given the >> added capabilities that multiple connections offer. >> >> > Please take integration test and write using this tool, and you will see > the reasons for this added verbosity. > > Ramesh.. > > _______________________________________________ > teiid-users mailing list > teiid-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/teiid-users > >