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@redhat.com>
To: "Barry Lafond" <blafond@redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev@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!