10:07 a.m.
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..
10:21 a.m.
New subject: [teiid-dev] VDB Versioning Feature
+1
I think removing the version makes a lot of sense, especially since we are deploying in
the container now. Version is not an attribute in other types of deployments and we should
follow the common practice to avoid confusion, as you said. Also, handling versions of the
same VDB using Jopr/JON for deployment would be tricky (if not impossible).
Ted
----- 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
10:25 a.m.
On Feb 8, 2010, at 10:07 AM, 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.
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.
Not sure if I agree with all the "confusion" you feel this causes, but I'm
certainly good with removing this capability. The user can always just give it a
different name, right?
Thanks,
JPAV
10:37 a.m.
New subject: [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
11:16 a.m.
New subject: [teiid-dev] VDB Versioning Feature
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.
On Feb 8, 2010, at 8:37 AM, Ken Johnson <kejohnso(a)redhat.com> wrote:
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-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
11:47 a.m.
New subject: [teiid-dev] VDB Versioning Feature
I carefully read through your reasoning, and I see only one main point
your are trying to make. "Transparency in client connection thru
multiple versions"
It really depends on the environment client is being deployed in.
Usually we recommend users to use some kind of connection pool, and
externalize those properties that are specific to a URL connection. For
example, if client is in a container they are using a JNDI name to get
the connection, nobody makes JDBC connection directly. IMO, we are
shifting the problem from one location to another as there is a
deference already.
Ramesh..
On Mon, 2010-02-08 at 11:37 -0500, Ken Johnson wrote:
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
>
11:58 a.m.
New subject: [teiid-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
10:56 a.m.
----- "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
5449
days inactive
5449
days old
teiid-designer-dev@lists.jboss.org
7 comments
7 participants
participants (7)
-
Amentra -
Barry Lafond -
John Doyle -
John Verhaeg -
Ken Johnson -
Ramesh Reddy -
Ted Jones