<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Verdana; font-size: 12pt; color: #000000'>(NOTE: Posted for Mike Walker. Can't get into the list admin right now to accept his post)<br><br>I agree with Ken's comments. This is a simple but extremely valuable <br>feature that emerged from a customer request. I took advantage of it <br>at a separate customer just last week. And the default behavior is <br>quite intuitive - the most recent version is the default, by default. <br>Have we had users or customers complain that this is confusing? If so, <br>then maybe docs or usability could be improved, but please don't <br>remove the feature, customers waited years for it.<br><br>Mike<br><br>----- Original Message -----<br>From: "Ken Johnson" <kejohnso@redhat.com><br>To: "Ramesh Reddy" <rareddy@redhat.com><br>Cc: teiid-designer-dev@lists.jboss.org, teiid-dev@lists.jboss.org<br>Sent: Monday, February 8, 2010 10:37:37 AM GMT -06:00 US/Canada Central<br>Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature<br><br>I believe some of the characterizations below paint an overly negative <br>view of the current versioning capabilities. These are generally <br>regarded by users as valuable and with the relatively new "default <br>version" property very flexible. More inline.<br>Ramesh Reddy wrote:<br>> In Teiid a VDB is always represented by its name and version. Together<br>> they both represented a unique name for VDB. Although a version<br>> represents a particular schema version, <br>><br>> 1) It is considered as a entirely different schema then that of the<br>> original VDB inside the Teiid runtime.<br>> <br>True, from a runtime standpoint, Teiid doesn't distinguish a new vdb <br>from a new version of an existing vdb. It's just another vdb.<br><br>> 2) Usually version numbers are presented in the repository systems with<br>> implicit rollback behavior. Teiid gives no such rollback functionality.<br>> <br>Repository is somewhat orthogonal here. While users sometimes deploy <br>from a repository, the active VDB version is distinct from the <br>repository version if the repo is indeed being used at all. Currently, <br>there is a roll-back capability in that a later version of a deployed <br>vdb can be deactivated and connections revert back to the previous <br>version (or the new default version if the default property is being used).<br><br>> 3) Confusion with automatic version upgrade. If a new VDB with same name<br>> is deployed, then version on this VDB is upgraded to next numerical<br>> number. The user does not even know what that version number is until<br>> they use some tool to figure out which version number that VDB is<br>> deployed under. This creates confusion.<br>> <br>This is not confusing, it's beneficial. For client apps that don't need <br>to know about a later version, they are not forced to change. This is <br>particularly important for minor, non-breaking changes. Client <br>applications should not be required to change simply because of a <br>version bump in the vdb. Client app changes are highly disruptive in an <br>organization - even replacing a JDBC client JAR that does not require <br>app code changes often needs layers of approval and test cycles.<br><br><br>> 4) If there are multiple VDB with different version numbers deployed in<br>> runtime and client is connecting with no explicit version number, then<br>> Teiid connects to "latest" or a VDB at "default" level. This again seems<br>> magical than honoring the explicit behavior.<br>> <br>This "magic" is good. Clients *can* be explicit if desired but do not <br>*have to* be explicit. Very powerful.<br><br>> 5) Schema version is generally not supported by any RDBMS vendors.<br>> <br>True but IMHO this is not a reason to drop the feature. Teiid, though <br>like a RDBMS in many ways is not a RDBMS. <br><br>> 6) In MMx product line this meant to represent the metadata repository<br>> version, but Teiid no longer has this concept. <br>> <br>This is not correct. the version is disconnected from the repository <br>entirely. It is simply a deployed version number.<br><br>> 7) It was a way to move production users from one version of the VDB to<br>> another with out interruptions. In our opinion, this is more for the<br>> development environments than prod.<br>> <br>Agree this will be more common in pre-production, particularly staging <br>environments due to the level of dynamism. However that does not mean <br>it's exclusive to pre-production. <br>> so, we would like to propose to remove this "version" feature from<br>> Teiid. If users want they can manage the this through explicit VDB<br>> names.<br>> <br>I disagree with this proposal as it will tighten the coupling between <br>client applications and vdbs and take away a layer of indirection and <br>flexibility that's valuable at the data services layer. <br>> Please let us know if you think this feature is worth keeping and why?<br>> <br>I do!<br><br><br>> Thanks<br>><br>> Ramesh..<br>><br>> _______________________________________________<br>> teiid-dev mailing list<br>> teiid-dev@lists.jboss.org<br>> https://lists.jboss.org/mailman/listinfo/teiid-dev<br>> <br><br><br>-- <br>Ken Johnson<br>Sr. Product Manager<br>JBoss Middleware Business Unit<br>Red Hat, Inc<br>978.392.3917<br>ken.johnson@redhat.com<br><br><br>_______________________________________________<br>teiid-designer-dev mailing list<br>teiid-designer-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/teiid-designer-dev<br></div></body></html>