8:31 p.m.
This is a change toward simple and focused. With the environmental information held by a
resource adapter connection factory the remaining properties of a translator are not
expected to change. It simplifies deployment greatly to have the vdb be self contained
than maintaining translators as another global entity.
In any event the deployment of a custom translator is also greatly simplified from before,
and should now become as easy as placing the JAR with your ExecutionFactory in the deploy
directory.
If a custom translator is changed (same name/class, but with different property
definitions), then the expectation is that the developer either has considered the impact
of the migration, such that the old translators property sets are compatible with the new.
If a new name is given and the old custom ExecutionFactory is removed, then a forced
migration would occur that requires the change of affected vdbs.
I don't necessarily see that as a limitation. We are steadily moving down the path
where from dynamic vdb or even designer perspective the physical model metadata is tied
directly to the translator used. This is especially true for LDAP and Salesforce, but is
even true for JDBC as native types, column names, etc., are not the same across all source
types. Only the loopback translator is a jack of all trades, but is of limited usefulness
for anything other than basic queries.
So to state this a different way, change your translator == change you physical model.
----- Original Message -----
From: "Van Halbert" <vhalbert(a)redhat.com>
To: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: teiid-dev(a)lists.jboss.org
Sent: Tuesday, May 25, 2010 1:11:14 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Translators in the "vdb.xml" file.
I vote the designer doesn't push the creation of a translator by adding additional
translator properties to the vdb.xml file. If the user created a custom connector,
they'll already be dealing with the task of deploying it to server(s). Also, if this
information is stored in the vdb (call it A) and then if the original custom translator is
changed (and replaced) and then vdb "A" is redeployed, don't we now have a
usability issue that has to be resolved on whether to replace the existing translator
properties or not. Carrying stale information in the vdb has caused us problems in the
past, so I would hope we wouldn't head back down that road on the first release.
I think this first release should be simple and focused. If the usability in the next
release drives it in this direction, then so be it.
On May 25, 2010, at 12:39 PM, John Verhaeg wrote:
On May 25, 2010, at 11:21 AM, Ramesh Reddy wrote:
> What I forgot mention in the earlier is, if user chooses one of the
> default "translators", then there is not really any need to define the
> XML fragment for the Translator at all inside the vdb.xml. Which I
> suspect in majority of the cases. Only when user wants to alter the
> default behavior, Teiid would need the additional translator fragment.
So presumably there will be some property on the translators that indicates whether its a
default translator?
Thanks,
JPAV
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
8:44 p.m.
New subject: Translators in the "vdb.xml" file.
Somewhat new to the translator nomenclature/architecture change...does this mean that each
VDB will have its own Translators, with their own connection pools, and its own
classloader, ensuring that VDBs will not share translator instances among each other?
If so, then this would be tremendously useful from a deployment perspective. You could
finally deploy a VDB and not have to choose whether to use embedded binding properties or
pre-existing properties created by a pre-existing VDB. Deploying a new version of a
translator would not require ripping all previous versions out and rebuilding them from
scratch, which is very tedious and requires downtime. You would have better guarantees
about the level of service a connection pool would provide, since there's no
possibility of two VDBs sharing a pool.
________________________________________
From: teiid-dev-bounces(a)lists.jboss.org [teiid-dev-bounces(a)lists.jboss.org] On Behalf Of
Steven Hawkins [shawkins(a)redhat.com]
Sent: Tuesday, May 25, 2010 11:31 AM
To: Van Halbert
Cc: teiid-dev(a)lists.jboss.org
Subject: Re: [teiid-dev] Translators in the "vdb.xml" file.
This is a change toward simple and focused. With the environmental information held by a
resource adapter connection factory the remaining properties of a translator are not
expected to change. It simplifies deployment greatly to have the vdb be self contained
than maintaining translators as another global entity.
In any event the deployment of a custom translator is also greatly simplified from before,
and should now become as easy as placing the JAR with your ExecutionFactory in the deploy
directory.
If a custom translator is changed (same name/class, but with different property
definitions), then the expectation is that the developer either has considered the impact
of the migration, such that the old translators property sets are compatible with the new.
If a new name is given and the old custom ExecutionFactory is removed, then a forced
migration would occur that requires the change of affected vdbs.
I don't necessarily see that as a limitation. We are steadily moving down the path
where from dynamic vdb or even designer perspective the physical model metadata is tied
directly to the translator used. This is especially true for LDAP and Salesforce, but is
even true for JDBC as native types, column names, etc., are not the same across all source
types. Only the loopback translator is a jack of all trades, but is of limited usefulness
for anything other than basic queries.
So to state this a different way, change your translator == change you physical model.
----- Original Message -----
From: "Van Halbert" <vhalbert(a)redhat.com>
To: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: teiid-dev(a)lists.jboss.org
Sent: Tuesday, May 25, 2010 1:11:14 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Translators in the "vdb.xml" file.
I vote the designer doesn't push the creation of a translator by adding additional
translator properties to the vdb.xml file. If the user created a custom connector,
they'll already be dealing with the task of deploying it to server(s). Also, if this
information is stored in the vdb (call it A) and then if the original custom translator is
changed (and replaced) and then vdb "A" is redeployed, don't we now have a
usability issue that has to be resolved on whether to replace the existing translator
properties or not. Carrying stale information in the vdb has caused us problems in the
past, so I would hope we wouldn't head back down that road on the first release.
I think this first release should be simple and focused. If the usability in the next
release drives it in this direction, then so be it.
On May 25, 2010, at 12:39 PM, John Verhaeg wrote:
On May 25, 2010, at 11:21 AM, Ramesh Reddy wrote:
> What I forgot mention in the earlier is, if user chooses one of the
> default "translators", then there is not really any need to define the
> XML fragment for the Translator at all inside the vdb.xml. Which I
> suspect in majority of the cases. Only when user wants to alter the
> default behavior, Teiid would need the additional translator fragment.
So presumably there will be some property on the translators that indicates whether its a
default translator?
Thanks,
JPAV
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
_______________________________________________
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
7:58 p.m.
New subject: Translators in the "vdb.xml" file.
On Tue, 2010-05-25 at 13:44 -0500, Michael Walker wrote:
Somewhat new to the translator nomenclature/architecture change...does
this mean that each VDB will have its own Translators, with their own
connection pools, and its own classloader, ensuring that VDBs will not
share translator instances among each other?
A translator is every thing except the connection semantics from
previous connector binding. The connection semantics are now called
"resource adapters" or "connectors (short for JCA connector).
The Translator code is deployed in the JBoss AS, however based on
configured properties it can instantiate a instance of this Translator,
which is used by the Teiid engine in same thread context to find
capabilities and translate into source specific queries.
The "resource adapter" is poolable, managable and possibly XA capable.
In the JDBC case this is nothing but a "data source" in an application
server. For other types of connections like LDAP and SF, we used JCA to
define the connection specifics.
So, the sharing model is Translators are VDB scoped, and connections
(can be) are shared.
If so, then this would be tremendously useful from a deployment
perspective. You could finally deploy a VDB and not have to choose
whether to use embedded binding properties or pre-existing properties
created by a pre-existing VDB. Deploying a new version of a translator
would not require ripping all previous versions out and rebuilding
them from scratch, which is very tedious and requires downtime. You
would have better guarantees about the level of service a connection
pool would provide, since there's no possibility of two VDBs sharing a
pool.
The argument is, since the Translator specific properties does not
change once the VDB is created, why not embed them along with the VDB so
that they are portable. Once we make them external, then we need to be
thinking about sharing the translators or how to migrate them between
environments.
Ramesh..
5084
days inactive
5084
days old
2 comments
3 participants
participants (3)
-
Michael Walker -
Ramesh Reddy -
Steven Hawkins