The point in renaming the old version would be to support a rollback correct? I don't see how there are applications specifically interested in connecting to the old version. I would argue for having a deployment rollback (regardless of whether its an overwrite or a rename) as an independent concern.

----- Original Message ----- From: "Larry O'Leary" <loleary(a)redhat.com&gt; To: "Steven Hawkins" <shawkins(a)redhat.com&gt; Cc: "John Doyle" <jdoyle(a)redhat.com&gt;, teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org Sent: Tuesday, February 16, 2010 10:22:59 PM GMT -06:00 US/Canada Central Subject: Re: [teiid-dev] [teiid-designer-dev] VDB Versioning Feature On Tue, 2010-02-16 at 17:37 -0500, Steven Hawkins wrote: > On point 2 what I believe we are trying to support is the promotion of > a "next" vdb to current. To that end versioning alone was not enough > to satisfy this feature, it also required the "default active" > designation - that's what Mike was referring to by it has taken years > to get this feature working. Even with using "default active" some > set of applications had to be updated to access a specific latest > version of a vdb prior to a new active default being chosen. The > takeaway here is that this can all be achieved without our current > notion of versioning if we have a simple operation "rename vdb" that > allow the next version to overwrite the current version. This is not > quite as user friendly - especially if there are multiple next > versions that are needed simultaneously, however I think we can safely > ignore that case. But it definitely simplifies things. I strongly believe that our users must have some kind of capability of deploying multiple versions of the same VDB. I think what you are saying makes sense and would accomplish our legacy version concept. The only note is that the rename process would also need to support the concept of renaming the older VDB to something prior to replacing it. In other words we need to satisfy the use case that our users are currently using: > Also the Teiid runtime is not the appropriate place to manage a > repository of VDBs. Unlike prior versions of MetaMatrix any active > vdb will have its metadata loaded when the system is starting up based > upon whether the vdb is marked as active. Having lots of older vdb > versions requires additional management by administrators to know > exactly which older ones are inactive. > ----- Original Message ----- > From: "Steven Hawkins" <shawkins(a)redhat.com&gt; > To: "John Doyle" <jdoyle(a)redhat.com&gt; > Cc: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org, "Ramesh Reddy" <rareddy(a)redhat.com&gt; > Sent: Monday, February 8, 2010 11:21:05 AM GMT -06:00 US/Canada Central > Subject: Re: [teiid-dev] [teiid-designer-dev] VDB Versioning Feature > > 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 !

a! > ssume 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&gt; > To: "Ramesh Reddy" <rareddy(a)redhat.com&gt; > 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&gt; 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 > > _______________________________________________ > teiid-dev mailing list > teiid-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/teiid-dev -- 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/

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.