Re: [teiid-dev] Proposal to further refine the JCA Connectors
by John Doyle
In general I get the reasons for this change, and think it's on whole a positive shift, but want to drill down into some areas.
https://jira.jboss.org/jira/browse/TEIID-1077 defines the split into translation/connection for individual connectors, and leaves some of them TBD but states that some will not be JCA for the connection.
Q: Are we 'enforcing' the division of these components through the APIs we're offering, or are we introducing a design pattern for connectors such that if you have a JCA connector for source X, you can just write a translator for Teiid. LDAP seems amenable for the design pattern case; I don't know that they are available or good but there are hits for LDAP-JCA connector. For the TBD sources, and forthcoming connectors, is the connector writer free ti implement the connection as they choose, or are we establishing some kind of Connection API that the translation layer will use and that must also be implemented?
Also, as part of the embedded Teiid for Designer which results from this change, its been proposed to me that we use DTP as the infrastructure to create and manage connections to sources for metadata and embedded execution. In an earlier thread we discussed using DTP in this way (minus the execution part) and decided it wasn't a good idea because it would cause confusion for the user to have all of these DTP connections that don't do anything in the DTP views/tools (I've since had a chat with John Graham who says there is precedent for using DTP in this way, although he agrees it is confusing). One implication of this decision would be that any connector that is to be executed in Designer will need a DTP Connectivity plugin. This significantly raises the bar for any custom connector that is not a modification of one of our connectors (eg, SQL translators for JDBC). It raises the bar not only in terms of effort, but it involves a different skill set (eclipse develppment) that we did not require before. The alternative seems to me that you have to deploy to Teiid test with your custom connector. Perhaps this limitation is acceptable, I just want to highlight it. We can or course provide examples, templates, etc to assist in this effort.
Still wrapping my hear around this...
~jd
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> I forgot to mention one more big plus going into this mode of
> dividing
> the connector binding is, supporting the "embedded" mode will be now
> possible for Teiid.
>
> After this change, essentially a host environment like JBoss AS is
> providing
>
> - data sources
> - transaction manager
> - xa terminator
> - Work Manager
> - JAAS provider (if authentication facilities are needed)
>
> to Teiid. If any foreign VM can provide these facilities, then Teiid
> will be fully operational. Except for the "data sources", which are
> very
> specific to the sources, every other item in the list can be
> supplemented with other available technologies.
>
>
> Thoughts?
>
> If there are no huge objections, we will soon follow up with
> implementation details, JIRAs etc. We would like make these changes
> for
> 7.0 M4.
>
> Ramesh..
>
> On Tue, 2010-04-27 at 09:42 -0400, Ramesh Reddy wrote:
> > After the 7.0 M3 release, and based some initial user feed back and
> > issues we have seen, we would like to propose change in the how the
> > Connector are defined.
> >
> > Traditionally in Teiid <= 6.2 and in Metamatarix
> >
> > Connector Binding = Translation Layer + Source Connection
> >
> > With the JCA changes, "Connector Binding" became the JCA Connector.
> > However, in the container a Source is defined with a "Data Source",
> > especially for relational sources the equation became
> >
> > Data Source = Managed Connection = Source Connection
> >
> > Connector Binding = Translation Layer + Data Source
> >
> > since the "Data Source" is defined with its own connector (i.e.
> -ds.xml
> > file) in the container, to support the "Connector Binding" in
> container,
> > we exposed the "Translation Layer" as another JCA Connector. So,
> now
> > this became
> >
> > Connector Binding = JCA Connector + Data Source
> >
> > But,
> >
> > JCA Connector = Managed Conection
> > Connector Binding = Managed Connection + Managed Connection
> >
> > Now, this became an issue to have a managed connection over managed
> > connection. Teiid does not *really* need the "Managed Connection"
> for
> > the translation layer, but it *really* needs in the "source
> connection",
> > so we want propose splitting the "Connector Binding" into two
> >
> > Translation Layer --> becomes a non-managed connection (not JCA)
> > Source Connection --> becomes managed connection (JCA)
> >
> > This has some pros and cons
> > Pros
> > 1) Translation layer would be independent of connection layer
> > 2) Since translation layer is independent of the environment
> changes,
> > they are portable and can be included in the VDB to migrate from
> one
> > environment to another.
> > 3) Since the Connection layer is independent of Translation layer
> it
> > becomes more general purpose JCA connector, that can be used with
> other
> > applications. With out these changes, this connector was previously
> only
> > to be used with Teiid. This also paves easier way to handle any type
> JCA
> > connector.
> >
> > Cons.
> > 1) Only JDBC Connector had two distinct configurations to define
> the
> > connector before. Going forward Teiid would need to devide the code
> in
> > all the Connectors between the translation layer and connection
> layer
> > and package as such. One as the regular jar file and as the JCA
> > connector.
> > 2) Two separate configuration files to define the layers
> > 3) Dependent jar management for the translation layer.
> > 4)
> >
> > _______________________________________________
> > teiid-dev mailing list
> > teiid-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev
>
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
15 years
Proposal to further refine the JCA Connectors
by Ramesh Reddy
After the 7.0 M3 release, and based some initial user feed back and
issues we have seen, we would like to propose change in the how the
Connector are defined.
Traditionally in Teiid <= 6.2 and in Metamatarix
Connector Binding = Translation Layer + Source Connection
With the JCA changes, "Connector Binding" became the JCA Connector.
However, in the container a Source is defined with a "Data Source",
especially for relational sources the equation became
Data Source = Managed Connection = Source Connection
Connector Binding = Translation Layer + Data Source
since the "Data Source" is defined with its own connector (i.e. -ds.xml
file) in the container, to support the "Connector Binding" in container,
we exposed the "Translation Layer" as another JCA Connector. So, now
this became
Connector Binding = JCA Connector + Data Source
But,
JCA Connector = Managed Conection
Connector Binding = Managed Connection + Managed Connection
Now, this became an issue to have a managed connection over managed
connection. Teiid does not *really* need the "Managed Connection" for
the translation layer, but it *really* needs in the "source connection",
so we want propose splitting the "Connector Binding" into two
Translation Layer --> becomes a non-managed connection (not JCA)
Source Connection --> becomes managed connection (JCA)
This has some pros and cons
Pros
1) Translation layer would be independent of connection layer
2) Since translation layer is independent of the environment changes,
they are portable and can be included in the VDB to migrate from one
environment to another.
3) Since the Connection layer is independent of Translation layer it
becomes more general purpose JCA connector, that can be used with other
applications. With out these changes, this connector was previously only
to be used with Teiid. This also paves easier way to handle any type JCA
connector.
Cons.
1) Only JDBC Connector had two distinct configurations to define the
connector before. Going forward Teiid would need to devide the code in
all the Connectors between the translation layer and connection layer
and package as such. One as the regular jar file and as the JCA
connector.
2) Two separate configuration files to define the layers
3) Dependent jar management for the translation layer.
4)
15 years
Re: [teiid-dev] Exposing connector defined metadata to tooling.
by John Doyle
I see how this makes sense in terms of reusing the current capabilities, but from a user interface design perspective I don't like the idea of fronting different sources with the JDBC importer. Doing it this way put a bunch of JDBC specific concerns/metadata into the import process that probably don't apply. I think it's a better UI approach to have a simpler generic importer that doesn't expose the JDBC metadata to the user, but exposes more simple relational concepts.
~jd
----- "Van Halbert" <vhalbert(a)redhat.com> wrote:
> In regards to building an importer, for a client we built a jdbc
> driver that provided the metadata from a spread sheet to build the
> models. I think that approach could very easily be used for a text
> file.
>
15 years
Re: [teiid-dev] Exposing connector defined metadata to tooling.
by John Doyle
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> On Thu, 2010-04-22 at 17:31 -0400, John Doyle wrote:
> > We could create importers for the different text file
> representations
> > for Text, Spreadsheets, Simple DB, etc. Or, perhaps the connectors
> > could expose the metadata that they provide to Teiid through a new
> API
> > that a 'generic' connector metadata importer could consume?
>
> Actually, we need both. +1 for both.
>
> We need a better support for for Text based data modeling. Teiid
> tooling
> support for this is sub par compared to other text importing tools.
> We
> should be able to point to a text file and try to guess the metadata
> and
> build the model/schema based on data contents. This is a feature
> missing
> in Teiid, which it should have had long time ago.
I agree with this, but this is a very tall order. In my former job we had a text file metadata importer and it was a boat anchor around the neck of whoever owned it, mostly for QA.
>
> Based on the "Connector Metadata" feature, if we have a generic
> Connector based importer, it would be useful to provide metadata
> facilities for less complicated sources (or even as the first step).
It would certainly be easier.
> However to drive a intelligent UI, we may need to put in little more
> work. Also, note that this paradigm is a shift from current Designer
> approach. Currently Designer, first builds the metadata and then
> creates/attaches to the Connector. In this scenario, it would need to
> create the Connector first, metadata next.
It'a a paradigm shift, but I also see it as a nice migration path from a dynamic VDB to a more mature/full use of Teiid capabilities. Let's say a user has a dynamic VDB with 3 connectors deployed for a year. If they could create models from the deployed connectors, they could then just copy the joins from from their app into virtuals and have the views that they already use without much effort.
>
>
> Ramesh..
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
15 years
Exposing connector defined metadata to tooling.
by John Doyle
In hacking up a Google Spreadsheets prototype, I've arrived a solution for connector metadata that is the same as the Text File Connector's connector driven metadata solution. I think an Amazon Simple DB solution lends itself to the same solution.
For anybody not familiar, a user creates a text file describing the metadata of the text file, the connector consumes the metadata file and creates metadata for Teiid, which exposes a dynamic VDB from the connector's metadata.
Eventually someone will want to model these sources in Designer to federate and virtualize them. For text files the user has to currently hand model. We could create importers for the different text file representations for Text, Spreadsheets, Simple DB, etc. Or, perhaps the connectors could expose the metadata that they provide to Teiid through a new API that a 'generic' connector metadata importer could consume?
~jd
15 years
Re: [teiid-dev] [teiid-designer-dev] VDB Versioning Feature
by Steven Hawkins
Before responding to you're conclusions below, I'd like to bring up that we currently report the vdb name as the catalog name through our system tables / jdbc metadata. So to remove vdb version we would either need to:
- not report the vdb name as the catalog to prevent apparent behavioral differences
- or change the vdb name in the vdb.xml to mean the catalog name
I assume we would take the latter approach. In that world creating a copy of a vdb does not require modifying the vdb.xml, just creating a new file. However we still need a unique way to refer to each vdb, so I would propose using the filename (designer already starts off with the assumption filename = vdbname). While it's possible through direct file deployments to do all kinds of crazy things (vdbs inside of zip files, sub folders, etc.), we can assume we're really only interested in this discussion with our "managed" view of the deploy directory. In which case we effectively do control the .vdb and -vdb.xml artifacts there.
To your points:
a) We could forgo even adding a copy vdb method if we put versioning as a primary concern in the deployVDB admin method. There are a couple of possible variants:
- overwrite the previous
- give a different filename to the vdb to deploy (pseudo active default behavior)
- give a different filename to the old vdb (which would be nothing more than a combined copy then deploy operation)
The current admin api method for vdb deployment can handle the first two cases - void deployVDB(InputStream contents, String fileName). It would probably make more sense in the last case for the admin to specify the name rather than to use auto-increment logic since a proper name allows you to know in advance how to change your urls. This means that we only have to add 1 additional method - boolean deployVDB(InputStream contents, String fileName, String oldVdbName) returning true if the old file existed. The associated tooling would then need to have deployment screens that specify if this deploy is an overwrite or what the backup name should be.
b) Other than keeping the vdb name / file name the same between deployments, there wouldn't be deployment related versioning concerns at design-time.
c) Seems like this follows from a.
----- Original Message -----
From: "Ken Johnson" <kejohnso(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "Larry O'Leary" <loleary(a)redhat.com>, "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Wednesday, April 21, 2010 12:49:50 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] [teiid-designer-dev] VDB Versioning Feature
I think this one has been flogged pretty well but I'd like to take
another crack at defining an alternative to the current version
number-based approach.
The principle value of the exising VDB versioning is as Ramesh
summarized: Client Transparency. We want a way for administrators to
introduce new versions of VDBs and seamlessly migrate clients that are
prepared to migrate as well as provide a simple means to allow laggard
clients to continue using an older/deprecated version of the VDB.
It seems this can be achieved largely through naming convention and good
process, with support from APIs/tools. From a user experience point of
view, the old solution had numerous benefits:
1. auto-version-increment prevented accidental overwrites on deployment
and eliminated the need for convention or best-practice
2. the name+ version number approach made it clear to administrators
that a set of VDBs are really the same thing but at different revision
levels.
3. the active-default allowed administrators to control the vdb used by
clients without disrupting the client code/configuration and didn't
break active client connections.
The replacement solution, though different in implementation, should
strive to have a similar level of user-friendliness:
Deployment via AdminAPI/shell and admin-console provide an opportunity
to constructively guide the user. For example warning them when
deploying a VDB with the same name as a currently deployed VDB. Or
giving them an option to rename the existing VDB to a "backup" name
prior to deploying the new version. We should help the user to not shoot
themselves in the foot. Deployment via file drop/copy doesn't afford
much opportunity to help users.
Best practices/scenarios should be documented so users understand how to
manage VDB "versions", not just in production but across the various
lifecycle stages (dev->test->prod). One usage scenario is for ModeShape
to be used as a repository of artifacts like VDB where administrators
can locate the "approved-for-deployment" VDB and then deploy it via URI
using AdminAPI/shell or admin-console. The best practices should provide
guidance here as well.
So, IMO option 1 can work if:
a) API and tooling operations are added to assist/protect the user
b) the Design-time developer is not responsible for anything related to
version management. This is an administrator activity.
c) most importantly: This continues to be offered as a feature. By that
I mean, this user need is acknowledged and Teiid provides
facilities/docs that address "VDB version management" as a capability
(even if multi-step) and not just "something a user can do if so inclined"
Thoughts?
-Ken
Steven Hawkins wrote:
> Is there any consensus here? Mike, Ken?
>
> As I see it:
>
> Option 1: get rid of the version concept altogether and possibly add a rename or copy vdb operation.
>
> Option 2: retain the version concept along with the active default designation. However setting the version will be a design time responsibility and file drop deployments will require different vdb file names for different versions.
>
> Option 3: ?
>
> And regardless of the scenario, deployers will need to ensure that only truly active vdbs are in an active state or suffer the memory/load costs.
>
> ----- Original Message -----
> From: "Larry O'Leary" <loleary(a)redhat.com>
> To: "Steven Hawkins" <shawkins(a)redhat.com>
> Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>, "John Verhaeg" <jverhaeg(a)redhat.com>
> Sent: Thursday, February 18, 2010 4:13:03 PM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
>
> On Thu, 2010-02-18 at 15:43 -0500, Steven Hawkins wrote:
>
>> At first glance in the scenario you list below, there's no need to
>> even bother with the promotion concept. You would just install the
>> new version (with a new name) and let apps point over to it as they
>> are ready.
>>
>
> Well, except for the fact that the clients do not want to change their
> connection properties. In other words, whatever the business as a whole
> deems as the latest and greatest, they are fine with. It is just that
> there is normally some stragglers that do things their way and disregard
> the business decision. In these cases, these stragglers would be
> responsible for updating their client connection properties to point to
> the renamed (previous version) VDB. Must like in legacy, they would
> update their connection properties to point to the old version.
>
>
>> To achieve the flow your suggesting without versioning would actually
>> require an extra step. Prior to promoting the next version, you would
>> need to deploy a duplicate of the current version with a new name.
>> Then the small set of apps not ready for the update would need to have
>> their connections pointed to the copy. Then you could safely promote
>> the next version without interrupting the lagging apps.
>>
>
> Right. In this scenario the new VDB would get the name of the old VDB
> so that client apps that were following the business decision would not
> need to make a change to get the newer VDB. And the lagging users would
> update their clients to point to the renamed VDB.
>
> I am not familiar with how we are packaging and naming VDBs to achieve
> this but in my opinion, making this a manual process seems logical and
> there would be no need for the system to automatically keep track of
> things.
>
> Furthermore, the functionality of "active-default" can be achieved the
> same way. Just make the active-default or latest version a base name.
> MyCoolSource.vdb. When a new version is available for integration
> testing but you are not ready to promote it to the "active-default" or
> "latest-version", deploy it as MyCoolSource_NextGen.vdb. In this case,
> users who want to use the NextGen version would simply change their
> client app to point to MyCoolSource_NextGen.vdb and everyone else will
> continue to use the "active-default" of MyCoolSource.vdb.
>
> When you are ready to move the "active-default" to the contents of
> MyCoolSource_NextGen.vdb then you simply copy MyCoolSource.vdb to
> MyCoolSource_OldGen.vdb, copy MyCoolSource_NextGen.vdb to
> MyCoolSource.vdb and voila. The only downside here is that
> MyCoolSource.vdb and MyCoolSource_NextGen.vdb are duplicates but I
> really don't see this as a problem.
>
> The naming convention would be up to business rules and we might want to
> make some kind of best practice suggestions to make this manageable but
> concept could be just as easily accomplished with version numbers in the
> name:
>
> MyCoolSource_v1.vdb
> MyCoolSource_v2.vdb
> MyCoolSource_v3.vdb
>
> And to achieve "active-default" or "latest-version" you would use
> MyCoolSource.vdb -> MyCoolSource_v3.vdb as a symbolic link or copy of
> the version you wanted to use.
>
> Of course, this logic all falls apart if the VDB actually contains a
> descriptor that defines its name to the system in which case the process
> is the same but a bit more complicated because you wouldn't be able to
> simply copy/symlink.
>
>
>
>> ----- Original Message -----
>> From: "Larry O'Leary" <loleary(a)redhat.com>
>> To: "John Verhaeg" <jverhaeg(a)redhat.com>
>> Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
>> Sent: Wednesday, February 17, 2010 11:38:00 AM GMT -06:00 US/Canada Central
>> Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
>>
>> On Wed, 2010-02-17 at 11:27 -0600, John Verhaeg wrote:
>>
>>> On Feb 17, 2010, at 10:44 AM, Larry O'Leary wrote:
>>>
>>>
>>>> Well there are two possibilities here. One is that there is a
>>>> roll-back. The other is that a new version of a VDB has been chosen as
>>>> the default but some of the organization is not ready to use the newer
>>>> version. In which case they would modify their clients to use the
>>>> previous version until they are ready to use the new one.
>>>>
>>>> So, in the "roll-back" scenario, the change is transparent to the
>>>> clients while in the "not-ready-to-upgrade" scenario the administrative
>>>> change is placed on the client. These are the two cases we have with
>>>> legacy customers.
>>>>
>>> Maybe I'm misunderstanding, but I don't believe your "new version"
>>> scenario makes practical sense. If an organization is implementing a
>>> new version and not ready to force that change on certain
>>> applications, departments, etc., wouldn't they want just that - no
>>> change to those areas? They're likely not going to impose the need to
>>> change a slew of existing clients to use the old VDB just to enable
>>> new clients to use the previous VDB name. Rather, they'd want to
>>> deploy the new VDB with a new name that only the new clients use.
>>> Then migration to the new VDB name for other clients could be easily
>>> scheduled and managed. Seems like the alternative would be a
>>> change-control nightmare.
>>>
>>>
>> Here is how it works. All clients are using an existing VDB and
>> development creates a new version of that VDB. They put it through all
>> the testing and identify any possible conflicts and changes that a
>> client may need to make. The VDB is then slated to be migrated to
>> production during their quarterly maintenance window. However, a small
>> group within the organization have not been able to complete all of
>> their testing necessary to use the new version of the VDB. In this
>> case, a business decision is made to proceed with the migration into
>> production and the "small group" is notified that they have until MM/dd
>> to complete their testing or they will need to point their clients at an
>> old version of the VDB. The old version will be left in production but
>> as a deprecated source.
>> --
>>
>> 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/
>>
>> _______________________________________________
>> teiid-designer-dev mailing list
>> teiid-designer-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
>>
>
>
15 years
Re: [teiid-dev] [teiid-designer-dev] VDB Versioning Feature
by Steven Hawkins
Is there any consensus here? Mike, Ken?
As I see it:
Option 1: get rid of the version concept altogether and possibly add a rename or copy vdb operation.
Option 2: retain the version concept along with the active default designation. However setting the version will be a design time responsibility and file drop deployments will require different vdb file names for different versions.
Option 3: ?
And regardless of the scenario, deployers will need to ensure that only truly active vdbs are in an active state or suffer the memory/load costs.
----- Original Message -----
From: "Larry O'Leary" <loleary(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>, "John Verhaeg" <jverhaeg(a)redhat.com>
Sent: Thursday, February 18, 2010 4:13:03 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
On Thu, 2010-02-18 at 15:43 -0500, Steven Hawkins wrote:
> At first glance in the scenario you list below, there's no need to
> even bother with the promotion concept. You would just install the
> new version (with a new name) and let apps point over to it as they
> are ready.
Well, except for the fact that the clients do not want to change their
connection properties. In other words, whatever the business as a whole
deems as the latest and greatest, they are fine with. It is just that
there is normally some stragglers that do things their way and disregard
the business decision. In these cases, these stragglers would be
responsible for updating their client connection properties to point to
the renamed (previous version) VDB. Must like in legacy, they would
update their connection properties to point to the old version.
> To achieve the flow your suggesting without versioning would actually
> require an extra step. Prior to promoting the next version, you would
> need to deploy a duplicate of the current version with a new name.
> Then the small set of apps not ready for the update would need to have
> their connections pointed to the copy. Then you could safely promote
> the next version without interrupting the lagging apps.
Right. In this scenario the new VDB would get the name of the old VDB
so that client apps that were following the business decision would not
need to make a change to get the newer VDB. And the lagging users would
update their clients to point to the renamed VDB.
I am not familiar with how we are packaging and naming VDBs to achieve
this but in my opinion, making this a manual process seems logical and
there would be no need for the system to automatically keep track of
things.
Furthermore, the functionality of "active-default" can be achieved the
same way. Just make the active-default or latest version a base name.
MyCoolSource.vdb. When a new version is available for integration
testing but you are not ready to promote it to the "active-default" or
"latest-version", deploy it as MyCoolSource_NextGen.vdb. In this case,
users who want to use the NextGen version would simply change their
client app to point to MyCoolSource_NextGen.vdb and everyone else will
continue to use the "active-default" of MyCoolSource.vdb.
When you are ready to move the "active-default" to the contents of
MyCoolSource_NextGen.vdb then you simply copy MyCoolSource.vdb to
MyCoolSource_OldGen.vdb, copy MyCoolSource_NextGen.vdb to
MyCoolSource.vdb and voila. The only downside here is that
MyCoolSource.vdb and MyCoolSource_NextGen.vdb are duplicates but I
really don't see this as a problem.
The naming convention would be up to business rules and we might want to
make some kind of best practice suggestions to make this manageable but
concept could be just as easily accomplished with version numbers in the
name:
MyCoolSource_v1.vdb
MyCoolSource_v2.vdb
MyCoolSource_v3.vdb
And to achieve "active-default" or "latest-version" you would use
MyCoolSource.vdb -> MyCoolSource_v3.vdb as a symbolic link or copy of
the version you wanted to use.
Of course, this logic all falls apart if the VDB actually contains a
descriptor that defines its name to the system in which case the process
is the same but a bit more complicated because you wouldn't be able to
simply copy/symlink.
> ----- Original Message -----
> From: "Larry O'Leary" <loleary(a)redhat.com>
> To: "John Verhaeg" <jverhaeg(a)redhat.com>
> Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Wednesday, February 17, 2010 11:38:00 AM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
>
> On Wed, 2010-02-17 at 11:27 -0600, John Verhaeg wrote:
> > On Feb 17, 2010, at 10:44 AM, Larry O'Leary wrote:
> >
> > > Well there are two possibilities here. One is that there is a
> > > roll-back. The other is that a new version of a VDB has been chosen as
> > > the default but some of the organization is not ready to use the newer
> > > version. In which case they would modify their clients to use the
> > > previous version until they are ready to use the new one.
> > >
> > > So, in the "roll-back" scenario, the change is transparent to the
> > > clients while in the "not-ready-to-upgrade" scenario the administrative
> > > change is placed on the client. These are the two cases we have with
> > > legacy customers.
> >
> > Maybe I'm misunderstanding, but I don't believe your "new version"
> > scenario makes practical sense. If an organization is implementing a
> > new version and not ready to force that change on certain
> > applications, departments, etc., wouldn't they want just that - no
> > change to those areas? They're likely not going to impose the need to
> > change a slew of existing clients to use the old VDB just to enable
> > new clients to use the previous VDB name. Rather, they'd want to
> > deploy the new VDB with a new name that only the new clients use.
> > Then migration to the new VDB name for other clients could be easily
> > scheduled and managed. Seems like the alternative would be a
> > change-control nightmare.
> >
>
> Here is how it works. All clients are using an existing VDB and
> development creates a new version of that VDB. They put it through all
> the testing and identify any possible conflicts and changes that a
> client may need to make. The VDB is then slated to be migrated to
> production during their quarterly maintenance window. However, a small
> group within the organization have not been able to complete all of
> their testing necessary to use the new version of the VDB. In this
> case, a business decision is made to proceed with the migration into
> production and the "small group" is notified that they have until MM/dd
> to complete their testing or they will need to point their clients at an
> old version of the VDB. The old version will be left in production but
> as a deprecated source.
> --
>
> 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/
>
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
--
Larry O'Leary <loleary(a)redhat.com>
Red Hat, Inc.
15 years
client version compatibility
by Steven Hawkins
Hello all,
Please see https://jira.jboss.org/jira/browse/TEIID-207 for changes related to version compatibility. The expectation is that with the next milestone the sql api will be tolerant to version changes - at least across 7.x. There will be some follow on changes before we get to the milestone. At the very least we'll probably need to change the session id back to something more amenable to a cluster rather than long.
Steve
15 years
Re: [teiid-dev] [teiid-users] Alternative scripting environment for AdminShell
by Steven Hawkins
https://jira.jboss.org/jira/browse/TEIID-1052 is the issue to track the approach below. The initial changes have been checked-in, so new shell and console executables and docs are available with a fresh build.
Yes, SQuirreL can display our query plan it just takes a Teiid specific SQuirrel plugin.
----- Original Message -----
From: "Ken Johnson" <kejohnso(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: rareddy(a)redhat.com, "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Thursday, April 15, 2010 1:10:08 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-users] [teiid-dev] Alternative scripting environment for AdminShell
Steven Hawkins wrote:
> 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
>
I agree with this approach. BTW, is there a way for SQuirreL to display
a Teiid query plan?
> ----- Original Message -----
> From: "Ken Johnson" <kejohnso(a)redhat.com>
> To: "Steven Hawkins" <shawkins(a)redhat.com>
> Cc: rareddy(a)redhat.com, "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
> 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>
>> 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
15 years
Re: [teiid-dev] [teiid-users] Alternative scripting environment for AdminShell
by Steven Hawkins
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>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: rareddy(a)redhat.com, "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
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>
> 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
15 years, 1 month