Re: [teiid-dev] Fwd: [teiid-designer-dev] Connection Factories
by John Doyle
Sorry Ramesh, I seem to have ignored this email.
Ken and I discussed this today. I don't think there should be a ConnectionProfile for each source. We could create profiles for each of the source we support, but I think there are two strong reasons not to.
1. The ConnectionProfile for non-JDBC sources would only be usable by our importers. For example, were I to create implement the DTP connection framework for Salesforce, I could modify the importer to the resulting ConnectionProfile. But to have the rest of the DTP framework use the ConnectionProfile I would have to implement the getting of the metadata for DTP, and the mapping of the query API to DTP, etc. It's a lot of work with no real value for us, and if we didn't do 'all' the work, it would be confusing for a knowledgeable user of DTP.
2. Some of import sources don't have a connection. XML to Relational and SOAP relational don't have to get their metadata from a 'connection' at all. As often as not the metadata comes from a file on disk, and the connector points elsewhere.
This doesn't mean that the importer or some other action can't produce the info needed for the ~ds.xml.
~john
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> Is there going to a "Connection Profile" for each source that Teiid
> Designer going to import/access in DTP? I know in previous versions
> Designer kept profiles locally, I am not sure the new behavior with
> DTP
> in the mix.
>
>
> On Mon, 2010-04-12 at 10:05 -0400, John Doyle wrote:
> > ----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> >
> > > On Fri, 2010-04-09 at 13:55 -0400, John Doyle wrote:
> > > >
> > > > It's not, it's DTP specific.
> > > >
> > > > I exported this in clear text, but encrypted is the default.
> > >
> > > Then for Teiid purposes it is not useful. If this file is in the
> > > "-ds.xml" format, Teiid could use it. Is there a way we could add
> > > "export as.." feature may be?
> >
> > For sure, should be pretty easy.
> > >
> > > Ramesh..
>
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years
Re: [teiid-dev] [teiid-users] Alternative scripting envrionment for AdminShell
by John Doyle
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
14 years
Teiid 7.0 M3
by Steven Hawkins
Hello all,
The long awaited Teiid 7.0 MS3 is now available - http://www.jboss.org/teiid/downloads.html. This milestone represents the next-generation of the Teiid runtime with deep integration into JBoss AS / JCA functionality. Check out the web based admin console, which is now available after installing the main dist, that shows off the marriage of these great technologies.
While not much will seem to have changed from a query feature standpoint, keep in mind that nearly all of our runtime and configuration and management logic has been rewritten for this release. With this major work out of the way, we should be able to deliver additional milestones, then betas/rc on a much better schedule.
Please give this milestone a try - and as always keep the issues coming if something needs addressed.
The Teiid Team
14 years
Re: [teiid-dev] Alternative scripting envrionment for AdminShell
by Steven Hawkins
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..
14 years
Re: [teiid-dev] [teiid-users] Alternative scripting environment for AdminShell
by Steven Hawkins
The full lineage from 4/5.x is:
svcmgr -> AdminShell T1
jdbcisql -> AdminShell T2
CommandShell -> AdminShell T3
And yes, something like:
connect(user, passwd)
exportConnectionFactory("TPCR_S2k", "test.xml")
...
is possible for admin logic. It's just not as technically appealing as using variables, since it requires making all of the contextual methods static, adding context management, internal methods to check the context state, etc. Also, by design, all of the Groovy Sql logic are designed to not leak statements or resultsets, which doesn't map very well to our logic that still try to hide them but made them available for possibly multiple operations (although they were likely to fail since we didn't typically reset the result set to the first row). The example highlighted that - where it was one call in Groovy to execute and print the results, but 2 in adminshell.
Let me restate something, we could support our old style sql iff:
- we reintroduced the context management logic (noting that we have a problem with denoting both the current sql and admin connections in a single prompt)
- re-implement all of our old sql handling logic and associated result set methods
- override the groovy shell line evaluation method to check for statements that look like sql (noting that the current logic has a lot of limitations)
Which in my mind is that same as saying that we should do it.
----- Original Message -----
From: "Larry O'Leary" <loleary(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:03:25 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-users] [teiid-dev] Alternative scripting envrionment for AdminShell
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(a)redhat.com>
> To: "Steven Hawkins" <shawkins(a)redhat.com>
> Cc: "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)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(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-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
--
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
14 years
Re: [teiid-dev] Alternative scripting envrionment for AdminShell
by Steven Hawkins
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/.
----- Original Message -----
From: "Paul Nittel" <pnittel(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)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(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
14 years
Re: [teiid-dev] [teiid-users] Alternative scripting envrionment for AdminShell
by Steven Hawkins
JUnit integration would not be lost. The integration now (basically just a static import of the Assert methods) can be ported exactly, and the result set logic can be ported as well.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Monday, April 12, 2010 12:11:40 PM GMT -06:00 US/Canada Central
Subject: Re: [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..
14 years
Alternative scripting envrionment for AdminShell
by Steven Hawkins
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
14 years
Re: [teiid-dev] Fwd: [teiid-designer-dev] Connection Factories
by John Doyle
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> On Fri, 2010-04-09 at 12:51 -0400, John Doyle wrote:
> > DTP has the capability to export a ConnectionProfile (equivalent to
> > our JDBCSource metadata in designer) to a file. We could use that
> as
> > a portable connection metadata. With default DTP features the user
> > could save it to any place on the filesystem (the project if they
> > chose) and add it to the vdb. We could add create an Action that
> > allowed a user to export the ConnectionProfile info for a given
> source
> > model into a VDB if we wanted.
>
> Could you please export a profile and send a sample? I want to see if
> this is in the -ds.xml format
>
It's not, it's DTP specific.
I exported this in clear text, but encrypted is the default.
> Thanks
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years
Fwd: [teiid-designer-dev] Connection Factories
by John Verhaeg
> On Apr 9, 2010, at 9:59 AM, John Doyle wrote:
>
>> I think so. I created a VDB and emailed it to you for further modification. You don't have access to my Teiid. How would you get this VDB to work?
>
> Well, that's exactly what we, including the Teiid team, are trying to allow for, and is specifically why specific data source information like URL, user name, etc., is not included or managed by Designer. If you've created a VDB that is being tested against a local database containing test data, then send it to me, I should be able to test it against a completely different instance of that test source. However, thinking about this scenario, I just realized we're not recording the connector name in the VDB's configuration file, which (unless I'm getting confused about what refers to what again) would also prevent your scenario from succeeding without the first user passing on that name to the second user outside of the tooling (e.g., via e-mail). I'll ask about this in the Teiid mailing list.
Guys, am I getting confused again, or don't we also need to store the connector name, in addition to the CF name/JNDI name, in the vdb.xml to allow for John's scenario above?
Thanks,
JPAV
14 years