11:44 a.m.
2) Created Modeling > "Create Data Source" and "Delete Data Source"
actions (maybe temporary actions) which extract Connection Profile from selected source
model, creates JNDI name and creates a Teiid Data Source if it doesn't exist. Verifies
the mechanics of storing connection info in models and using it create Teiid DS artifacts
when necessary.
These should definitely be temporary. The VDB is responsible for creating the JNDI name
and that name should certainly never be stored in the model since it's tied to the
workspace UUID and path within that workspace.
I agree the actions should be temporary.
As far as JNDI name, since the JNDI name is really constructed with "Workspace"
info (i.e. workspace uuid, project path, model name) AND DQP is responsible for
communicating with Teiid (i.e. managing Data Sources) then the JNDI name should be managed
in DQP. In all cases, the JNDI name should be given to the VDB when models are added, just
like Translators... OR users given the option of "searching/selecting" existing
Translators and Data Sources. (See my comments yesterday on
https://jira.jboss.org/browse/TEIIDDES-411 )
3) On start-up, the ExecutionAdmin now has the smarts to search workspace for physical
models and determine if models have matching JNDI names on the default Teiid server. This
is a little tricky because we only get Data Source Names (JNDI) from Teiid API and
can't get any properties to determine if the DS connection properties (i.e. type, URL,
etc) match the Connection Profile info in a model. Based on our workspace logic to
"clean-up" preview VDB artifacts on user events (close project, exit Designer,
etc...) we are intending to NOT need to know anything more than the DS names.
We should always be able to match a model against its JNDI name without the need for
properties. I don't understand why this would be tricky?
Simple scenario, 1) user creates relational model from one URL Oracle source. 2) User
previews model (JNDI name is auto-generated) 3) User changes Connection Profile for Model
to different URL Oracle Source 4) user previews model (JNDI name is auto-generated but DS
already exists but with wrong URL. So we either need to "clean up JNDI" names
when CP's change for model or find some other way to match. Without DS
"type" or URL info, there's no way to know what's behind a DS on a Teiid
Server.. short of opening up JON/JOPR. Again, JNDI names, though simple, are tied closely
with Connection info, which is exclusive to the DQP. Hence DQP manages JNDI names as well
as Data Sources on server. VDB's don't need to know anything but the value of the
JNDI name string.
Barry
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
To: "Barry Lafond" <blafond(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Wednesday, June 16, 2010 11:07:06 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] 7.0 Progress - 6/16/10
On Jun 16, 2010, at 10:34 AM, Barry Lafond wrote:
2) Created Modeling > "Create Data Source" and "Delete Data Source"
actions (maybe temporary actions) which extract Connection Profile from selected source
model, creates JNDI name and creates a Teiid Data Source if it doesn't exist. Verifies
the mechanics of storing connection info in models and using it create Teiid DS artifacts
when necessary.
These should definitely be temporary. The VDB is responsible for creating the JNDI name
and that name should certainly never be stored in the model since it's tied to the
workspace UUID and path within that workspace.
3) On start-up, the ExecutionAdmin now has the smarts to search workspace for physical
models and determine if models have matching JNDI names on the default Teiid server. This
is a little tricky because we only get Data Source Names (JNDI) from Teiid API and
can't get any properties to determine if the DS connection properties (i.e. type, URL,
etc) match the Connection Profile info in a model. Based on our workspace logic to
"clean-up" preview VDB artifacts on user events (close project, exit Designer,
etc...) we are intending to NOT need to know anything more than the DS names.
We should always be able to match a model against its JNDI name without the need for
properties. I don't understand why this would be tricky?
4) Data Sources are now showing up in the Teiid server view, along with the available
Translators. I'm currently providing a display name == model name instead of showing
the actual generated JNDI because it'll be ugly and look something like:
8d9b22ab-f4ab-48c0-a6cd-b4d4501b81a5__TestProject_B.TestFolder.BooksSQL_B. User will see
"BooksSQL_B"
Why are we showing translators in this view? What can the user do with that information?
Seems like this is yet another topic we've been round and round on, coming to
consensus every week, then rehashing it the following week...
The whole point of showing anything in this view was for manual user cleanup of stale,
orphaned data sources due to application crashes, no-longer-used workspaces (this may
currently be a moot point since we cleanup on application close), etc. The user needs to
see the entire name to determine whether it's his artifact. Seems like this is yet
another topic we've been round and round on, ... wow, deja-vu!
Thanks,
JPAV