Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
by Steven Hawkins
Since we can safely ignore legacy notions of our repository the features John's features below are a good succinct place to start.
In the container, 1 is just a replacement of the existing vdb with one of the same name. Clients wishing to use the latest do not need to take any action.
2, even with versions, is not entirely easy. Some vdb version would need to be set to the active default and some subset of connecting applications would still use an explicit version. Presumably this is done for the purpose of migration. That is, as soon as the new version is blessed, it will be marked as the new default. There are two points to be made here. The first is that this is not a common practice or even something that would be desirable in most environments. Typically your testing will be done in separate instances, an integration environment vs. production, which doesn't require simultaneous deployment of multiple versions in the production instance. The second is that this same flow could be done without our notion of versions if the act of promotion is just to undeploy/redeploy the new vdb over the old vdb. The only issue is that the applications connecting to the "explicit new vdb version" would not be pointing to anything after promotion, but if we assume that their connection strings are supposed to change anyway, the could just as easily be pointed at the live vdb.
----- Original Message -----
From: "John Doyle" <jdoyle(a)redhat.com>
To: "Ramesh Reddy" <rareddy(a)redhat.com>
Cc: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org
Sent: Monday, February 8, 2010 10:56:20 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] [teiid-designer-dev] VDB Versioning Feature
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> In Teiid a VDB is always represented by its name and version.
> Together
> they both represented a unique name for VDB. Although a version
> represents a particular schema version,
>
...
>
> so, we would like to propose to remove this "version" feature from
> Teiid. If users want they can manage the this through explicit VDB
> names.
>
> Please let us know if you think this feature is worth keeping and
> why?
I think this deserves some careful consideration. I think its important that we maintain the capability to:
1) Deploy a 'newer version' of a VDB that clients will use without any changes to clients.
and, conversely, from a user's perspective,
2) Deploy a 'new version' of a VDB while maintaining the older version such that existing clients will continue to use the old on without change.
Currently VDB version in the connection is the mechanism. I won't argue against getting rid of version, but if we do I think we need to have a different way to accomplish the above.
>
> Thanks
>
> Ramesh..
>
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
15 years, 11 months
VDB Versioning Feature
by Ramesh Reddy
In Teiid a VDB is always represented by its name and version. Together
they both represented a unique name for VDB. Although a version
represents a particular schema version,
1) It is considered as a entirely different schema then that of the
original VDB inside the Teiid runtime.
2) Usually version numbers are presented in the repository systems with
implicit rollback behavior. Teiid gives no such rollback functionality.
3) Confusion with automatic version upgrade. If a new VDB with same name
is deployed, then version on this VDB is upgraded to next numerical
number. The user does not even know what that version number is until
they use some tool to figure out which version number that VDB is
deployed under. This creates confusion.
4) If there are multiple VDB with different version numbers deployed in
runtime and client is connecting with no explicit version number, then
Teiid connects to "latest" or a VDB at "default" level. This again seems
magical than honoring the explicit behavior.
5) Schema version is generally not supported by any RDBMS vendors.
6) In MMx product line this meant to represent the metadata repository
version, but Teiid no longer has this concept.
7) It was a way to move production users from one version of the VDB to
another with out interruptions. In our opinion, this is more for the
development environments than prod.
so, we would like to propose to remove this "version" feature from
Teiid. If users want they can manage the this through explicit VDB
names.
Please let us know if you think this feature is worth keeping and why?
Thanks
Ramesh..
15 years, 11 months
Removing dependencies on DQP from Salesforce and Web Service importer.
by John Doyle
Hey Dan,
We were discussing changing the dependency of the SalesForce and WSDL to Relational importers from com.metamatrix.modeler.dqp.config.ConfigurationManager to the JDBCImportPostProcessor. When I looked into that class last night I found that it's not going to work for me without substantial change because its very JDBC specific. My importers don't set the same binding properties as the JDBC importer, and don't have to edit classpaths and such. It seems to me that the ConfigurationManager is really the right abstraction for what I need. It allows me to find the right connector type and set any values I want on it. Each of my importers has different values to set in the bindings. Is there some reason that we can't leave ConfigurationManager as the public API (assuming that it might change in this release because of the JCA changes)?
~john
15 years, 11 months
7.0 Dev Plans
by John Doyle
Hey Barry,
In an earlier thread(http://lists.jboss.org/pipermail/teiid-designer-dev/2010-January/0... we talked about integrating the DTP stuff for 7.1. The doc you just put up (http://community.jboss.org/wiki/TeiidDesigner70DevelopmentPlans) says we're going to "Modify DQP/SQL Explorer plugins to execute VDB via DTP's jdbc connection to Teiid." I'd like to clarify what this means.
The work I have done so far with DTP enables a user to do the following in the DTP perspectives.
1) Create connections to Teiid (6.X only for now, but 7.0 should only be minor tweaks because it's just a JDBC connection).
2) View the metadata for the VDB.
3) Use the DTP graphical SQL statement building tools to create queries.
4) Execute SQL statements on the VDB and view results.
I have a suggestion from Steve H that I need to test out that will allow me to integrate the DTP query plan view capability also.
I would like to target the DTP related work to 7.0. Specifically, get rid of the SQL Explorer plugins and execute VDBs via DTPs perspectives. As it is there are a a lot of unknowns in what we're taking on for 7.0, so maybe I'm trying to bite off too much. What do you think?
On a related issue, the DTP code is currently in my private repos, and I was working on an Athena build for it. I thought it would be a good idea to build it as it's own feature so that a non-Designer user of Teiid (someone building a web app on the VDB for instance) could download it without a dependence on Designer, and it could also be built into Designer. To that end I was figuring it could live in the JBTools repos. We can discuss this part on another thread I suppose as its a different issue.
~jd
15 years, 11 months