Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
by Steven Hawkins
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>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>, "John Verhaeg" <jverhaeg(a)redhat.com>
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:
> At first glance in the scenario you list below, there's no need to
> even bother with the promotion concept. You would just install the
> new version (with a new name) and let apps point over to it as they
> are ready.
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.
> To achieve the flow your suggesting without versioning would actually
> require an extra step. Prior to promoting the next version, you would
> need to deploy a duplicate of the current version with a new name.
> Then the small set of apps not ready for the update would need to have
> their connections pointed to the copy. Then you could safely promote
> the next version without interrupting the lagging apps.
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.
> ----- Original Message -----
> From: "Larry O'Leary" <loleary(a)redhat.com>
> To: "John Verhaeg" <jverhaeg(a)redhat.com>
> Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Wednesday, February 17, 2010 11:38:00 AM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
>
> On Wed, 2010-02-17 at 11:27 -0600, John Verhaeg wrote:
> > 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.
> >
>
> Here is how it works. All clients are using an existing VDB and
> development creates a new version of that VDB. They put it through all
> the testing and identify any possible conflicts and changes that a
> client may need to make. The VDB is then slated to be migrated to
> production during their quarterly maintenance window. However, a small
> group within the organization have not been able to complete all of
> their testing necessary to use the new version of the VDB. In this
> case, a business decision is made to proceed with the migration into
> production and the "small group" is notified that they have until MM/dd
> to complete their testing or they will need to point their clients at an
> old version of the VDB. The old version will be left in production but
> as a deprecated source.
> --
>
> 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/
>
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
--
Larry O'Leary <loleary(a)redhat.com>
Red Hat, Inc.
14 years, 8 months
Proposed Schema for "ConfigurationInfo.def" file
by Ramesh Reddy
Based on the JCA changes to the VDB artifact and its configuration the
current "ConfigurationInfo.def" file needs to be modified.
I have attached the XML schema and a sample XML file showing the new
format of this file. This format closely resembles the old format with
few additions to lot of removal of other elements.
This same XML file will serve as
1) Configuration for the VDB
2) Configuration to define a "Dynamic VDB"
3) Will serve as the persisted format in the container, when a user
modifies the associated connector bindings to a model using any
administrative tools.
Please take look at this and let me know if there are any suggestions to
improve upon.
Thank you.
Ramesh..
14 years, 10 months
Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
by Steven Hawkins
At first glance in the scenario you list below, there's no need to even bother with the promotion concept. You would just install the new version (with a new name) and let apps point over to it as they are ready.
To achieve the flow your suggesting without versioning would actually require an extra step. Prior to promoting the next version, you would need to deploy a duplicate of the current version with a new name. Then the small set of apps not ready for the update would need to have their connections pointed to the copy. Then you could safely promote the next version without interrupting the lagging apps.
----- Original Message -----
From: "Larry O'Leary" <loleary(a)redhat.com>
To: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Wednesday, February 17, 2010 11:38:00 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
On Wed, 2010-02-17 at 11:27 -0600, John Verhaeg wrote:
> 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.
>
Here is how it works. All clients are using an existing VDB and
development creates a new version of that VDB. They put it through all
the testing and identify any possible conflicts and changes that a
client may need to make. The VDB is then slated to be migrated to
production during their quarterly maintenance window. However, a small
group within the organization have not been able to complete all of
their testing necessary to use the new version of the VDB. In this
case, a business decision is made to proceed with the migration into
production and the "small group" is notified that they have until MM/dd
to complete their testing or they will need to point their clients at an
old version of the VDB. The old version will be left in production but
as a deprecated source.
--
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/
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 10 months
Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
by Steven Hawkins
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>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "John Doyle" <jdoyle(a)redhat.com>, 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>
> To: "John Doyle" <jdoyle(a)redhat.com>
> Cc: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org, "Ramesh Reddy" <rareddy(a)redhat.com>
> 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 we!
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>
> To: "Ramesh Reddy" <rareddy(a)redhat.com>
> 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> 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/
14 years, 10 months
Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
by Steven Hawkins
Not to beat a dead horse, but I would like to clarify the points below. I think we all agree that point 1 is satisfied by just deploying a new vdb over an existing one.
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.
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>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)lists.jboss.org, "Ramesh Reddy" <rareddy(a)redhat.com>
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 we assume 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>
To: "Ramesh Reddy" <rareddy(a)redhat.com>
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> 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
14 years, 10 months
Re: [teiid-designer-dev] 7.0 Release Planning - REV 2
by John Doyle
I don't know how update sites really function, I'm just saying that I think the majority of users would want both features and that if it's possible we should default so that users get both. Maybe this isn't a feature of update sites.
----- "John Verhaeg" <jverhaeg(a)redhat.com> wrote:
>
On Feb 11, 2010, at 2:05 PM, John Doyle wrote:
> OK thanks for the clarification. Optional is good, but I think we should turn the option 'on' by default if possible. I think the use case for a design env without a runtime environment is valid, but limited.
>
>
I'm not sure what you mean by 'option', but to clarify a bit more, the main motivation behind the 2 features revolves around ensuring the project remains useable by itself, meaning outside of bundled distribution options such as within JBT or JBDS. Nothing else Barry discussed is a motivating factor, but rather side-effects of moving in this direction. Thus, there would be one feature in our update site for designer that does not include any runtime capability, and another feature that adds runtime to the base feature. The core feature would, by definition, but more limited than both together, but still usable just to model. In the future, we could get the runtime feature to not depend upon the design-time feature, potentially allowing for a more lightweight installation by testers and the like that only care about runtime and not the modeling aspects. So, not sure if the idea of turning on an option applies.
>
Thanks,
>
JPAV
>
>
> _______________________________________________ teiid-designer-dev mailing list teiid-designer-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 11 months
7.0 Release Planning - REV 2
by Barry Lafond
Please feel free to comment on the following portion of our 7.0 Release plans .
To better accommodate changes required for JBoss Tools integration and Teiid 7.0 integration we propose to modify/refactor our current code-base in the following way.
We propose to separate Teiid Designer code into Design-time code and Run-time code resulting in two installable Eclipse-based feature sets.
•
Design-time is specified as all modeling exercises short of creating/editing/executing VDB's or previewing data.
•
Users can create model projects, import/create/edit models, organize models into projects and folders, check-in/check-out from their favorite repository, etc....
•
UDF modeling will still be available.
•
Importing data for model creation will NOT auto-create connectors and data preview feature will not be available.
•
The VDB will NOT be a visible concept.
•
Run-time refers to any data preview or VDB execution logic
•
This feature will initially depend on installed Design-time features to run.
• Users can c reate/edit/ execute VBD's .
•
Importing data for model creation will auto-create connectors.
•
Data Preview will be available for design-time modeling.
•
Auto-deploy VDB to Teiid server (stretch)
•
Modify DQP/SQL Explorer plugins to execute VDB via DTP's jdbc connection to Teiid.
• No Designer-related jar management for UDF of JDBC/JDBC connections (assumed to be in place on server)
Motivating factors for making these changes to Designer include:
•
Creation of lighter-weight tool which is NOT dependent on Teiid runtime code-base will facilitate easier development of the modeling features.
•
Eliminates duplicate code maintenance between Designer and Teiid.
•
Allows independent run-time feature development.
• Simplifies run-time features by removing non-essential Eclipse dependencies (EMF, UML2, etc...)
There will be a few milestones related to our 7.0 release
M1 - Design-time tooling feature set (modeling only)
•
separation of any preview data or vdb execution from modeling
•
keep current JDBC import methodology
M2 - Run-time execution tooling feature set (add-on to design-time feature set)
•
utilizes current SQL Explorer
M3 - Integration of Designer with DTP functionality
•
remove SQL Explorer and replace with common DTP data source querying
•
customize through DTP to perform preview data queries.
Barry LaFond
Teiid Designer Project
14 years, 11 months
Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
by John Doyle
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(a)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(a)redhat.com>
> To: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>,
> "teiid-dev" <teiid-dev(a)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(a)redhat.com>
> To: "Ramesh Reddy" <rareddy(a)redhat.com>
> Cc: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)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(a)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(a)redhat.com
>
>
> _______________________________________________
> 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-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 11 months
Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
by Ted Jones
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(a)redhat.com>
To: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)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(a)redhat.com>
To: "Ramesh Reddy" <rareddy(a)redhat.com>
Cc: teiid-designer-dev(a)lists.jboss.org, teiid-dev(a)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(a)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(a)redhat.com
_______________________________________________
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
14 years, 11 months
Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
by Paul Nittel
Ramesh:
I'm on the fence as to whether or not this feature should be kept and will gladly defer to others, however:
I don't think it's particularly confusing (but I come from a VMS background where every file had a version #).
I'm not sure how versions play in the microcontainer world, so maybe this would be more trouble for the users than it's worth.
I don't understand why the design features, or lack thereof, in "true RDBMS" products must influence our features. In this case, I don't buy it. :-)
Cheers,
-------
Paul Nittel
JBoss Sr. Quality Assurance Engineer
Red Hat, Inc.
314-336-2907 (81-62907)
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: teiid-dev(a)lists.jboss.org, teiid-designer-dev(a)lists.jboss.org
Sent: Monday, February 8, 2010 10:07:10 AM GMT -06:00 US/Canada Central
Subject: [teiid-dev] VDB Versioning Feature
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.
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-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years, 11 months
