10:27 p.m.
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.
~jd
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
As a separate tool it is focused enough to support features such as
sql command completion and other much beyond what we can offer :)
Integration with Groovy isn't really the right path coming from this
direction. You would rather see us support more functionality through
sql, like the old admin vdb - which could be added back easily with
the reduced admin logic and admin objects that map to xml (sqlxml).
We should even support in line definition of procedures, which may
require changes in the tool to support, but would mitigate the need
for introducing another language.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "Paul Nittel" <pnittel(a)redhat.com>, "teiid-users"
<teiid-users(a)lists.jboss.org>, "teiid-dev"
<teiid-dev(a)lists.jboss.org>
Sent: Monday, April 12, 2010 6:31:27 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Alternative scripting envrionment for
AdminShell
On Mon, 2010-04-12 at 17:22 -0400, Steven Hawkins wrote:
> 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/.
As separate tool it seems verbose and fragmented offering. If we can
integrate these tools into groovy or add missing features as pulgins
into these tools seems like the right path. The both tools above have
their own shell environments, integrating with them or into groovy,
both
may be challenging.
Henplus, seems to have extensive features, and seems to have the
simultaneous name based connections, so it definitely gets my vote if
we
decide go this route.
Ramesh..
_______________________________________________
teiid-users mailing list
teiid-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-users
11:41 p.m.
New subject: [teiid-users] 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..
5:44 a.m.
New subject: [teiid-users] Alternative scripting envrionment for AdminShell
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.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: "Steven Hawkins" <shawkins(a)redhat.com>, "teiid-users"
<teiid-users(a)lists.jboss.org>, "teiid-dev"
<teiid-dev(a)lists.jboss.org>, "Paul Nittel" <pnittel(a)redhat.com>
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..
6:06 a.m.
New subject: [teiid-users] Alternative scripting envrionment for AdminShell
----- "Steven Hawkins" <shawkins(a)redhat.com> 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?
Yes.
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.
Nice open solution. I like it.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: "Steven Hawkins" <shawkins(a)redhat.com>, "teiid-users"
<teiid-users(a)lists.jboss.org>, "teiid-dev"
<teiid-dev(a)lists.jboss.org>, "Paul Nittel" <pnittel(a)redhat.com>
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..
6:15 a.m.
New subject: [teiid-users] 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>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: "Steven Hawkins" <shawkins(a)redhat.com>, "teiid-users"
<teiid-users(a)lists.jboss.org>, "teiid-dev"
<teiid-dev(a)lists.jboss.org>, "Paul Nittel" <pnittel(a)redhat.com>
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
--
Ken Johnson
Sr. Product Manager
JBoss Middleware Business Unit
Red Hat, Inc
978.392.3917
ken.johnson(a)redhat.com
7:14 a.m.
New subject: [teiid-users] Alternative scripting envrionment for AdminShell
On Tue, 2010-04-13 at 16:44 -0400, 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?
Yes.
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.
Not sure about this. Although I agree that we want to make the Admin
API easier to maintain, the entire reason for exposing it was so that
non-development users could use it. Originally this was to be
accomplished via a SQL extension (provided by the Admin VDB). A user
wants to find out what the state of a connector is or what the state of
a VDB is by simply executing a query. The concept of the Admin Shell
provided this. A user needs the ability to write simple commands (no
need for reading an API or JavaDoc) to accomplish simple tasks regarding
administration.
--- pseudo ---
Connect To MMServerA
Get Status of Connector ConnectorA
Get Status of Connector ConnectorB
Disconnect
If Either ConnectorA or ConnectorB Status is Unavailable, Exit With
Error Code 2
Exit With No Error Code
--- pseudo ---
So, even though we may have falling short in this within Admin Shell,
the concept was still there and an Admin Shell script could be easily
integrated with a user shell script (bash, cmd, etc). By utilizing the
Admin API, it also allowed this type of scripting to be done remotely
allowing for a single script/instance to monitor or perform operations
on many server instances.
I am not so sure it is an issue of the "shell" being present as it is
that a simple set of functions be provided that wrap the more complex
operations offered through the API.
Although, now that we will be living in the container, I am sure that we
can expose these simple functions/operations through other methods. For
example, in the MBean world, I can invoke operations using Twiddle. So,
if these common administrative and monitoring tasks can be exposed via a
remote operation, then maybe the container could provide the missing
functionality.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: "Steven Hawkins" <shawkins(a)redhat.com>, "teiid-users"
<teiid-users(a)lists.jboss.org>, "teiid-dev"
<teiid-dev(a)lists.jboss.org>, "Paul Nittel" <pnittel(a)redhat.com>
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
--
Larry O'Leary
Middleware Support Engineering Group
Global Support Services
Red Hat, Inc.
loleary(a)redhat.com
1.866.LINUX70 (+1.314.336.2990) xt 81-62909
Office: +1.314.336.2909
Mobile: +1.618.420.7623
--
Looking to carve out IT costs?
http://www.redhat.com/carveoutcosts/
5138
days inactive
5138
days old
5 comments
5 participants
participants (5)
-
John Doyle -
Ken Johnson -
Larry O'Leary -
Ramesh Reddy -
Steven Hawkins