5:12 p.m.
On Apr 9, 2010, at 9:59 AM, John Doyle wrote:
> I think so. I created a VDB and emailed it to you for further modification. You
don't have access to my Teiid. How would you get this VDB to work?
Well, that's exactly what we, including the Teiid team, are trying to allow for, and
is specifically why specific data source information like URL, user name, etc., is not
included or managed by Designer. If you've created a VDB that is being tested against
a local database containing test data, then send it to me, I should be able to test it
against a completely different instance of that test source. However, thinking about this
scenario, I just realized we're not recording the connector name in the VDB's
configuration file, which (unless I'm getting confused about what refers to what
again) would also prevent your scenario from succeeding without the first user passing on
that name to the second user outside of the tooling (e.g., via e-mail). I'll ask
about this in the Teiid mailing list.
Guys, am I getting confused again, or don't we also need to store the connector name,
in addition to the CF name/JNDI name, in the vdb.xml to allow for John's scenario
above?
Thanks,
JPAV
6:15 p.m.
On Fri, 2010-04-09 at 10:12 -0500, John Verhaeg wrote:
Guys, am I getting confused again, or don't we also need to store the
connector name, in addition to the CF name/JNDI name, in the vdb.xml
to allow for John's scenario above?
The Connector *only* comes in the picture when you are creating a CF.
period. This information is contained *only* in a CF properties. Then,
"vdb.xml" has the JNDI name for the CF.
CF --> instance of --> Connector
VDB --> has --> Model (+1) --> has reference to --> CF (+1)
When user 2 gets the VDB, and not sharing containers
1) he has choice to define the CF for the names defined under "vdb.xml"
in his container.
2) If user 1 can also pass in the "-ds.xml" files for the CF, he can
deploy them along with the vdb
If they are sharing the containers, they do not need to share any thing.
They both have access to the VDB and its CF.
Hope this helps.
Ramesh..
CF == Connection Factory
(+1) denotes more than one
6:25 p.m.
On Apr 9, 2010, at 11:15 AM, Ramesh Reddy wrote:
The Connector *only* comes in the picture when you are creating a
CF.
period. This information is contained *only* in a CF properties. Then,
"vdb.xml" has the JNDI name for the CF.
CF --> instance of --> Connector
VDB --> has --> Model (+1) --> has reference to --> CF (+1)
When user 2 gets the VDB, and not sharing containers
1) he has choice to define the CF for the names defined under "vdb.xml"
in his container.
2) If user 1 can also pass in the "-ds.xml" files for the CF, he can
deploy them along with the vdb
The concern here is definitely when the 2 users are NOT sharing the same container. How
would user 2 know which connector to hook up a new CF to? IOW, how would he have any clue
the source type should be Oracle, for instance? Do we have to include *-ds.xml files to
accomplish this? Thus far, we haven't been planning on doing this...
Thanks,
JPAV
6:51 p.m.
DTP has the capability to export a ConnectionProfile (equivalent to our JDBCSource
metadata in designer) to a file. We could use that as a portable connection metadata.
With default DTP features the user could save it to any place on the filesystem (the
project if they chose) and add it to the vdb. We could add create an Action that allowed
a user to export the ConnectionProfile info for a given source model into a VDB if we
wanted.
~jd
----- "John Verhaeg" <jverhaeg(a)redhat.com> wrote:
On Apr 9, 2010, at 11:15 AM, Ramesh Reddy wrote:
> The Connector *only* comes in the picture when you are creating a
CF.
> period. This information is contained *only* in a CF properties.
Then,
> "vdb.xml" has the JNDI name for the CF.
>
> CF --> instance of --> Connector
>
> VDB --> has --> Model (+1) --> has reference to --> CF (+1)
>
>
> When user 2 gets the VDB, and not sharing containers
> 1) he has choice to define the CF for the names defined under
"vdb.xml"
> in his container.
> 2) If user 1 can also pass in the "-ds.xml" files for the CF, he
can
> deploy them along with the vdb
The concern here is definitely when the 2 users are NOT sharing the
same container. How would user 2 know which connector to hook up a
new CF to? IOW, how would he have any clue the source type should be
Oracle, for instance? Do we have to include *-ds.xml files to
accomplish this? Thus far, we haven't been planning on doing this...
Thanks,
JPAV
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
7:31 p.m.
On Fri, 2010-04-09 at 12:51 -0400, John Doyle wrote:
DTP has the capability to export a ConnectionProfile (equivalent to
our JDBCSource metadata in designer) to a file. We could use that as
a portable connection metadata. With default DTP features the user
could save it to any place on the filesystem (the project if they
chose) and add it to the vdb. We could add create an Action that
allowed a user to export the ConnectionProfile info for a given source
model into a VDB if we wanted.
Could you please export a profile and send a sample? I want to see if
this is in the -ds.xml format
Thanks
7:26 p.m.
On Fri, 2010-04-09 at 11:25 -0500, John Verhaeg wrote:
Do we have to include *-ds.xml files to accomplish this? Thus far,
we
haven't been planning on doing this...
No, I am not saying to include this. If we can export CF, that is one
way to share. Or user1 can go the deploy directory of the container to
grab the -ds.xml files.
Ramesh..
7:42 p.m.
On Apr 9, 2010, at 12:26 PM, Ramesh Reddy wrote:
No, I am not saying to include this. If we can export CF, that is
one
way to share. Or user1 can go the deploy directory of the container to
grab the -ds.xml files.
Then I'm confused about the motivation behind the attempt to make VDBs more portable.
I thought the idea was to make it easy to move a VDB from one environment to another,
specifically thinking about promotion, like from dev to test to prod. If the CF names
generally match the model names, how would, say, a prod admin ever know the appropriate
connector to assign the CF to? If this info still has to be passed around verbally or via
some other exported entity, then why are we taking it out of the VDB in the first place?
Thanks,
JPAV
7:46 p.m.
Good question.... "model" names means nothing to Teiid CF's (outside of our
hidden preview vdb)
So maybe this makes a stronger case for exposing the CF's to Designer and assisting
the Developers in "Clearly" setting the proper CF's, viewing CF's on
multiple servers, transferring/copying CF's between servers.
Barry
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
To: rareddy(a)redhat.com
Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Friday, April 9, 2010 12:42:37 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Fwd: [teiid-designer-dev] Connection Factories
On Apr 9, 2010, at 12:26 PM, Ramesh Reddy wrote:
No, I am not saying to include this. If we can export CF, that is one
way to share. Or user1 can go the deploy directory of the container to
grab the -ds.xml files.
Then I'm confused about the motivation behind the attempt to make VDBs more portable.
I thought the idea was to make it easy to move a VDB from one environment to another,
specifically thinking about promotion, like from dev to test to prod. If the CF names
generally match the model names, how would, say, a prod admin ever know the appropriate
connector to assign the CF to? If this info still has to be passed around verbally or via
some other exported entity, then why are we taking it out of the VDB in the first place?
Thanks,
JPAV
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
11:32 p.m.
On Fri, 2010-04-09 at 12:42 -0500, John Verhaeg wrote:
Then I'm confused about the motivation behind the attempt to make
VDBs
more portable.
Having the environment specific details inside a VDB does more
damage
than it useful in terms of portability. VDB artifact itself, user should
be able to move around with out the connection specific details.
I thought the idea was to make it easy to move a VDB from one
environment to another, specifically thinking about promotion, like
from dev to test to prod.
We had the right mix in old MM when it was supporting
the ".def" file
out side the VDB. The only issue with that design was, the ".def" file
also defined specifics about the models that were inside VDB file, which
is separate artifact. Current approach is hybrid of both. VDB has all
the info about itself, no dependencies to environment. The DS files
have the connection details.
The motivation is clean separation of concerns and deployment of these
artifacts. We no longer have the Console like tools manage at finest
details nor we want to. The way we promote now is, keep the VDB same
every where, and have the "-ds.xml" for each environment separate. Then
using the admin tools deploy them separately, not fix the artifact using
Admin tool before user can deploy.
When you write a WAR file as application developer, you do not define
the connection details inside your code or inside the war file, you look
up a datasource using the JNDI. This case is no different.
If the CF names generally match the model names, how would, say, a
prod admin ever know the appropriate connector to assign the CF to?
Who said CF
names are model names? CF name is JNDI name of some resource
deployed in container. There is something called "source-name" and
"jndi-name" to support the multi-source bindings. In the Designer case,
since 99% of the time, we are dealing with the single source, then use
the "model" name as "source-name" not for the JNDI name. Please see
the
VDB.XML schema.
If this info still has to be passed around verbally or via some
other
exported entity, then why are we taking it out of the VDB in the first
place?
I am not saying to take it out or keep it. We now have an *option* to
take it out. If we need to keep it, provide the "-ds.xml" file through
tooling.
Ramesh..
5407
days inactive
5407
days old
8 comments
4 participants
participants (4)
-
Barry Lafond -
John Doyle -
John Verhaeg -
Ramesh Reddy