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

Mon Feb 8 14:02:05 EST 2010

I think we're getting hung up on what containers do or what DRBMs do.  What's it going to cost to keep this feature?  Is it worth it or not?

I think it's very useful.  I think we would be doing ourselves a long term disservice by pulling this feature and would eventually put it or something like it back in based upon demand.  We can and should make recommendations and have best practices about how clients should manage their client connections but the reality for the client is often more complex than we can know.  They might not even own their client connection, they could have a SLA to support client connections for orgs that do not have a central decision making point.

I think we can afford to be disruptive on the VDB deployment/administration side.  I think we have to tread much more lightly on the client side.  Make the admin/designer of the VDB jump through the hoops he needs to jump through, but it would be bad to regress on this I think.

~jd

----- "Ted Jones" <tejones at redhat.com> wrote:

> It seems to me that we are somewhat limited in what we can support
> from the previous deployment model as compared to what we can do in a
> container environment. Think of other deployment models in the
> container world (e.g. wars, ears, connectors, etc.).  There is no
> concept of multiple versions for anything else in a container, right?
> The file to be deployed has to be renamed in order to not overwrite
> the existing deployment. I'm not saying we couldn't add the smarts to
> make this work, but it would be fugly and unconventional in our new
> container world.
> 
> The version field may still prove valuable as a property to indicate
> the version of the deployed vdb, but only one version would/could ever
> be deployed at one time.
> 
> Again I should mention that deploying two versions of the same VDB
> (same file name) and having them co-exist in the same container is not
> possible in Jopr/JON and that is due to the restrictions of the
> container's deployment paradigm.
> 
> Ted 
> 
> ----- Original Message -----
> From: "Barry Lafond" <blafond at redhat.com>
> To: "teiid-designer-dev" <teiid-designer-dev at lists.jboss.org>,
> "teiid-dev" <teiid-dev at lists.jboss.org>
> Sent: Monday, February 8, 2010 11:58:24 AM GMT -06:00 US/Canada
> Central
> Subject: Re: [teiid-dev] [teiid-designer-dev]  VDB Versioning Feature
> 
> 
> 
> (NOTE: Posted for Mike Walker. Can't get into the list admin right now
> to accept his post) 
> 
> I agree with Ken's comments. This is a simple but extremely valuable 
> feature that emerged from a customer request. I took advantage of it 
> at a separate customer just last week. And the default behavior is 
> quite intuitive - the most recent version is the default, by default.
> 
> Have we had users or customers complain that this is confusing? If so,
> 
> then maybe docs or usability could be improved, but please don't 
> remove the feature, customers waited years for it. 
> 
> Mike 
> 
> ----- Original Message ----- 
> From: "Ken Johnson" <kejohnso at redhat.com> 
> To: "Ramesh Reddy" <rareddy at redhat.com> 
> Cc: teiid-designer-dev at lists.jboss.org, teiid-dev at lists.jboss.org 
> Sent: Monday, February 8, 2010 10:37:37 AM GMT -06:00 US/Canada
> Central 
> Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature 
> 
> 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 at lists.jboss.org 
> > https://lists.jboss.org/mailman/listinfo/teiid-dev 
> > 
> 
> 
> -- 
> Ken Johnson 
> Sr. Product Manager 
> JBoss Middleware Business Unit 
> Red Hat, Inc 
> 978.392.3917 
> ken.johnson at redhat.com 
> 
> 
> _______________________________________________ 
> teiid-designer-dev mailing list 
> teiid-designer-dev at lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev 
> 
> _______________________________________________
> teiid-dev mailing list
> teiid-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev