Re: [teiid-dev] [teiid-designer-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/
16 years
Re: [teiid-dev] [teiid-designer-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
16 years
Re: [teiid-dev] XML SOAP Connectors
by John Doyle
I've given this a lot of thought as well, perhaps from a different direction than you. I hate to answer a question with a question, but here it is. Are the dependencies really the issue? As you describe below, other JBoss projects use 3rd party libraries as well.
I'm generally in favor of using JAX-WS (cxf) rather than Axis, it's a newer and better spec in my opinion. But I don't know that the change is worth the effort. I changed the XML_Relational connector to JAX-WS this because I was unable to find a way to keep Axis from DOMing the response doc, which caused memory issues.
Bringing in the ESB makes a much more powerful and flexible solution for federating with XML. It provides a better environment for manipulating XML that we will ever produce. It's a solution we should recommend, but we still need a capable XML/SOAP/REST story of our own if we going to call ourselves 'Data Federation' IMHO.
We've talked about adding SQL/XML functions to the engine. If we did this, I think we could get away with simple HTTP and JAX_WS connectors to source the XML and rely upon the SQL/XML and XQuery functions in Teiid to manipulate it. If a user wanted a stronger solution they could then use the ESB or other JBoss WS.
I agree that we want to get to a new 'permanent' way in the 7.0-7.1 time frame. Our window for disruptive changes will get much smaller after 7.1.
~jd
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> Last couple days I have been looking into alternative ways to XML
> Connectors than what Teiid currently have to execute SOAP based calls
>
> Teiid currently uses mix of some grown client code using Apache's
> HTTP
> Client and Axis 1.3 libraries. It has been desire to remove these
> dependencies from multiple libraries and more tightly integrate with
> the
> JBoss technologies.
>
> For that I looked at
>
> JBoss ESB: They provide something called "SoapClient" which based on
> "SoapUI" based client library. Using the ESB is nice, as it removes
> the
> transport level concerns from Teiid and places them on the ESB,
> however
> I feel that, we may be pulling in more dependencies and tooling
> around
> this may be an issue.
>
> JAX-WS and JBoss WS: JAX-WS provides a "Service" and "Dispatch"
> interface similar to Axis's "Call" interface. This seems promising,
> and
> supports HTTP Basic auth. Looks like JBoss WS implementation of the
> JAX-WS (native, metro, cxf) all support WS-Security. CXF is even
> based
> WSSJ which is also used by Axis.
>
> Although, ESB based solution is one fix for all this different XML
> messages from different sources and can fix our transport issues,
> this
> is moving issue another level and based on Teiid's SOAP usage model,
> this can introduce more latency in the calls along with tooling
> issues.
>
> IMO, JAX-WS based solution is good, but not sure what is preferred
> implementation between native, metro and cxf from JBoss WS. Also,
> there
> is good bit of development involved on Teiid to replace the code. But
> I
> feel this work must be done in 7.0 or 7.1 releases.
>
> I welcome any volunteers who is knowledgeable in this area to comment
> and help us with the solution.
>
> Thank you.
>
> Ramesh..
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
16 years
Re: [teiid-dev] [teiid-designer-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
16 years, 1 month
XML SOAP Connectors
by Ramesh Reddy
Last couple days I have been looking into alternative ways to XML
Connectors than what Teiid currently have to execute SOAP based calls
Teiid currently uses mix of some grown client code using Apache's HTTP
Client and Axis 1.3 libraries. It has been desire to remove these
dependencies from multiple libraries and more tightly integrate with the
JBoss technologies.
For that I looked at
JBoss ESB: They provide something called "SoapClient" which based on
"SoapUI" based client library. Using the ESB is nice, as it removes the
transport level concerns from Teiid and places them on the ESB, however
I feel that, we may be pulling in more dependencies and tooling around
this may be an issue.
JAX-WS and JBoss WS: JAX-WS provides a "Service" and "Dispatch"
interface similar to Axis's "Call" interface. This seems promising, and
supports HTTP Basic auth. Looks like JBoss WS implementation of the
JAX-WS (native, metro, cxf) all support WS-Security. CXF is even based
WSSJ which is also used by Axis.
Although, ESB based solution is one fix for all this different XML
messages from different sources and can fix our transport issues, this
is moving issue another level and based on Teiid's SOAP usage model,
this can introduce more latency in the calls along with tooling issues.
IMO, JAX-WS based solution is good, but not sure what is preferred
implementation between native, metro and cxf from JBoss WS. Also, there
is good bit of development involved on Teiid to replace the code. But I
feel this work must be done in 7.0 or 7.1 releases.
I welcome any volunteers who is knowledgeable in this area to comment
and help us with the solution.
Thank you.
Ramesh..
16 years, 1 month
Re: [teiid-dev] [teiid-designer-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
16 years, 1 month
VDB Versioning Feature
by Ramesh Reddy
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..
16 years, 1 month
Re: [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
16 years, 1 month
Re: [teiid-dev] [teiid-designer-dev] VDB Versioning Feature
by Steven Hawkins
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
16 years, 1 month
distributed sessions
by Steven Hawkins
Hello all,
As part of the container move for 7.0 we have been contemplating removing our notion of distributed sessions, since that feature is not provided for us by the container. The breakdown of this change would be.
pros:
- no custom tokening mechanism required, which eliminates concerns over exposing the token value (in cache, between client and server, etc.)
- we never distributed any state beyond the authentication with the session, so eliminating this feature removes any expectation of transparent client failover.
cons:
- cached values in a cluster that are at a session level would not be available at other cluster members since a re-authentication would occur at each member. This affects plans and cached values using the hasRole, env, user functions, etc.
Any thoughts?
16 years, 1 month