Re: [teiid-dev] [teiid-designer-dev] VDB Versioning Feature

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&gt; To: "Steven Hawkins" <shawkins(a)redhat.com&gt; Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org&gt;, "teiid-dev" <teiid-dev(a)lists.jboss.org&gt;, "John Verhaeg" <jverhaeg(a)redhat.com&gt; 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: 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. 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. -- Larry O'Leary <loleary(a)redhat.com&gt; Red Hat, Inc.