8:37 a.m.
Taking a second look after functionality of the translator and
connections factories,
Translators are immutable across all the deployment environments. Once
defined they should never change from environment to environment.
Currently they are defined in global scope. i.e. a given translator
instance is global to the Teiid runtime instance, that is shared among
VDBs. This makes them to defined in their own deployment file.
However, if VDB need to be migrated to another environment, the user
will also need to migrate the corresponding translators. This adds
complexity in terms of migration. This can be avoided, by making the
translators VDB scoped, by defining them inside the "vdb.xml" file.
Then, they go along with VDB, so need to for migration of multiple
artifacts from environment to environment.
As per functionality this will not change any thing from what has been
discussed before. This adds minor additional changes to "vdb.xml", and
VDB, translator deployers. Translator functionality Designer would need
to designed such that they are written to vdb.xml, instead of calling
Admin API to create a translator. I will make changes to the vdb.xml's
schema file note the changes required.
Thanks. Let me know if you have any questions.
Ramesh..
12:05 p.m.
On May 25, 2010, at 8:37 AM, Ramesh Reddy wrote:
As per functionality this will not change any thing from what has
been
discussed before. This adds minor additional changes to "vdb.xml", and
VDB, translator deployers. Translator functionality Designer would need
to designed such that they are written to vdb.xml, instead of calling
Admin API to create a translator. I will make changes to the vdb.xml's
schema file note the changes required.
But we don't really want to own the format of these translator files. Can't we
just modify the admin API method in question to hand us back the translator files so we
can then write them to the vdb.xml?
Thanks,
JPAV
11:11 a.m.
On Tue, 2010-05-25 at 12:05 -0500, John Verhaeg wrote:
But we don't really want to own the format of these translator files.
Can't we just modify the admin API method in question to hand us back
the translator files so we can then write them to the vdb.xml?
Designer is already building a properties object for the Translator to
be called with Admin API. What I am saying is, I will provide the
schema, which will be similar to "model" fragment with bunch of name
value pairs. Designer can use that to build the XML. If you are using
JAXB for xml marshaling it would be no different.
This also removes the verbose call to the Teiid runtime, so that this
can be done with out active server connection.
Ramesh..
12:29 p.m.
This sounds too hackish to me, so I'm pushing back... again... :)
• Designer has no real concept of a "translator". We deal with Connection
Profiles and NOT Server/Teiid properties. It only needs a translator to perform runtime
(query) operations.
•
The Properties that we do pass you for the addTranslator() method will be provided from
Teiid in the first place, right? The keys will be from Teiid's PropertyDefinitions.
•
Teiid cares about translator.xml files (or whatever they are called). Teiid Designer
really doesn't care other than to make sure one exists within a VDB, if that is the
new requirement.
Barry
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: teiid-dev(a)lists.jboss.org
Sent: Tuesday, May 25, 2010 11:11:11 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Translators in the "vdb.xml" file.
On Tue, 2010-05-25 at 12:05 -0500, John Verhaeg wrote:
But we don't really want to own the format of these translator files.
Can't we just modify the admin API method in question to hand us back
the translator files so we can then write them to the vdb.xml?
Designer is already building a properties object for the Translator to
be called with Admin API. What I am saying is, I will provide the
schema, which will be similar to "model" fragment with bunch of name
value pairs. Designer can use that to build the XML. If you are using
JAXB for xml marshaling it would be no different.
This also removes the verbose call to the Teiid runtime, so that this
can be done with out active server connection.
Ramesh..
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
12:36 p.m.
On Tue, 2010-05-25 at 13:29 -0400, Barry Lafond wrote:
* Designer has no real concept of a "translator". We
deal with
Connection Profiles and NOT Server/Teiid properties. It only
needs a translator to perform runtime (query) operations.
I understand
that Designer does not directly use any of the translator.
Designer needs this before preview can work.
* The Properties that we do pass you for the addTranslator()
method will be provided from Teiid in the first place, right?
The keys will be from Teiid's PropertyDefinitions.
This will not
change, same as before
* Teiid cares about translator.xml files (or whatever they are
called). Teiid Designer really doesn't care other than to make
sure one exists within a VDB, if that is the new requirement.
all I am
saying is instead calling the "addTranslator", marshal it to
XML and place it in vdb.xml. I am sorry, but I do not see a fairly large
new requirement. Sure, this is change in direction from original
connector stuff. The split between the translation layer and connection
layer is paving for further refinement the strategy as we implement the
functionality.
The bottom line is, this will make the user VDB migration between
multiple environments easier.
Ramesh..
11:21 a.m.
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.
Ramesh..
On Tue, 2010-05-25 at 12:05 -0500, John Verhaeg wrote:
But we don't really want to own the format of these translator
files.
Can't we just modify the admin API method in question to hand us back
the translator files so we can then write them to the vdb.xml?
12:39 p.m.
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
12:37 p.m.
On Tue, 2010-05-25 at 12:39 -0500, 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?
You can think of these as "named" translators out-of-the-box, that never
change between the environments. My thinking is in the absence of the
translator fragment in the vdb.xml, Teiid will try to resolve against
the "default" translator list. So, I do not see any need to explicitly
say that they are default.
Ramesh..
3:14 p.m.
But how are we supposed to know when to create the fragment or when not to?
On May 25, 2010, at 12:37 PM, Ramesh Reddy wrote:
On Tue, 2010-05-25 at 12:39 -0500, 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?
>
You can think of these as "named" translators out-of-the-box, that never
change between the environments. My thinking is in the absence of the
translator fragment in the vdb.xml, Teiid will try to resolve against
the "default" translator list. So, I do not see any need to explicitly
say that they are default.
Ramesh..
Thanks,
JPAV
4:53 p.m.
On Tue, 2010-05-25 at 15:14 -0500, John Verhaeg wrote:
But how are we supposed to know when to create the fragment or when
not to?
I can provide a list of available translators through Admin API, if user
chooses one of them then we can ignore. Otherwise we need to make user
create a new one.
1:11 p.m.
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
5333
days inactive
5333
days old
10 comments
4 participants
participants (4)
-
Barry Lafond -
John Verhaeg -
Ramesh Reddy -
Van Halbert