2:12 p.m.
Thanks that clears a lot up. I like the approach. A few more questions though:
- Don't really see how you can create the preview VDB right after creating the model.
How do you know what Teiid server the connector will come from? Seems like this will have
to wait until the connector is chosen/created. Unless you are assuming there is one and
only one Teiid server used to preview. Also would assume then that if the user has not
designated any servers then preview would be disabled.
- Don't understand why one and only one Teiid server has to be picked for preview. Why
can't you preview a model on a Teiid server running say Teiid version N. And also
preview the same model using a different source binding to a different Teiid server that
is running version N+1. Not sure how if this is a valuable use case or if there are any
valuable use cases but it doesn't make sense to me to limit them to only one.
- Doesn't seem like we currently can get workspace indexes for just one model or for a
set of selected models. This will be new functionality right?
- Don't think Teiid would care about the VDB name (correct me if I'm wrong). We
should come up with the names and pass in via API. And since we'll have a programmatic
way of creating the names we wouldn't need to keep a mapping.
Cheers
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
To: "Daniel Florian" <dflorian(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Friday, March 26, 2010 1:30:41 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
On Mar 26, 2010, at 12:32 PM, Daniel Florian wrote:
I'm still trying to wrap my head around what you guys are proposing. Could you explain
in a step-by-step fashion how you envision this working? Use a Designer scenario something
like this:
1. physical model created via import
2. connector assigned to model
3. user previews model
4. model is changed
5. user previews again
6. user ends Designer session
7. user starts Designer session
8. user previews model
9. model is deleted
1. User creates a model in the workspace
2. We use Teiid preview API to create new preview VDB and add that model's
workspace index to it (potentially asynchronously). I would think the same method that
creates the VDB on the server would also add the index to it passed as a parameter. The
VDB would be named something unique, something like model name + UUID (Not sure which side
would be responsible for creating this name).
3. If it's a virtual model, the preview VDB is updated via the API as dependencies
are added to it (again, possibly async).
4. When the user previews the model, we prompt for connector information, and use one
or more API methods to bind the model to the connector and/or preview. If Teiid
doesn't allow us to do this late binding, we wouldn't be able to do the previous
steps asynchronously.
5. If user previews again without changes, Teiid has to update nothing.
6. If the user makes a change to the model or one of its dependencies, an update
method is called on the API. Note, changes to physical models may affect multiple preview
models (including the preview for the physical model itself).
7. As models are deleted, the preview API would need to be notified. Again, for
physical models this may involve more than one preview VDB.
So, this splits up communication over the wire into smaller units, but doesn't reduce
the overall communication. But we don't have to manage anything locally other than the
mapping between the models and their associated preview VDBs. Regarding the server used,
we could either also prompt the user for this information the first time a model is
previewed (again, preventing async operations earlier in the process), or alternatively we
could have the user choose the server to use for preview when the Teiid connection is
created, requiring less information from the user during the first preview. Presumably,
the user would be able to switch to a different Teiid later, but that would be a pretty
heavyweight operation requiring lots of shuffling on Designer and copying/cleanup wrt the
previous Teiid used for preview.
What would the API calls look like along the way?
Don't know for sure; that's up to Ramesh and his team. But I would assume just
simple things like createPreviewVdb(), vdb.addModel(), vdb.preview(), etc.
Does Designer have a local version of the VDB?
No, that's definitely one of the benefits both to us and the user experience. The
artifacts involved stay hidden to both the user and the Designer, while hopefully
eliminating any confusion to the user as to how this all works under the covers..
Does Designer still convert our indexes to theirs (didn't know we were doing this)?
No, Teiid will do this. We no longer have to worry about the Teiid index format.
Is Designer persisting any data relating to preview (source bindings for instance)?
I'd think not as long as Teiid would persist these preview VDB's, but we'd
probably persist the mapping between workspace models and preview VDBs.
Thanks,
JPAV