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.

I believe some of the characterizations below paint an overly negative view of the current versioning capabilities. These are generally regarded by users as valuable and with the relatively new "default version" property very flexible. More inline. Ramesh Reddy 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, > > 1) It is considered as a entirely different schema then that of the > original VDB inside the Teiid runtime. > True, from a runtime standpoint, Teiid doesn't distinguish a new vdb from a new version of an existing vdb. It's just another vdb. > 2) Usually version numbers are presented in the repository systems with > implicit rollback behavior. Teiid gives no such rollback functionality. > Repository is somewhat orthogonal here. While users sometimes deploy from a repository, the active VDB version is distinct from the repository version if the repo is indeed being used at all. Currently, there is a roll-back capability in that a later version of a deployed vdb can be deactivated and connections revert back to the previous version (or the new default version if the default property is being used). > 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. > This is not confusing, it's beneficial. For client apps that don't need to know about a later version, they are not forced to change. This is particularly important for minor, non-breaking changes. Client applications should not be required to change simply because of a version bump in the vdb. Client app changes are highly disruptive in an organization - even replacing a JDBC client JAR that does not require app code changes often needs layers of approval and test cycles. > 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. > This "magic" is good. Clients *can* be explicit if desired but do not *have to* be explicit. Very powerful. > 5) Schema version is generally not supported by any RDBMS vendors. > True but IMHO this is not a reason to drop the feature. Teiid, though like a RDBMS in many ways is not a RDBMS. > 6) In MMx product line this meant to represent the metadata repository > version, but Teiid no longer has this concept. > This is not correct. the version is disconnected from the repository entirely. It is simply a deployed version number. > 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. > Agree this will be more common in pre-production, particularly staging environments due to the level of dynamism. However that does not mean it's exclusive to pre-production. > 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. > I disagree with this proposal as it will tighten the coupling between client applications and vdbs and take away a layer of indirection and flexibility that's valuable at the data services layer. > Please let us know if you think this feature is worth keeping and why? > I do! > Thanks > > Ramesh.. > > _______________________________________________ > teiid-dev mailing list > teiid-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/teiid-dev >

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?

Thanks Ramesh.. _______________________________________________ teiid-designer-dev mailing list teiid-designer-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-designer-dev