2:23 p.m.
Thx John and Dan,
All good questions and all good answers.
Just had a conversation with S&R and they have arrived at a suggested methodology that
seems pretty simple and extensible and should clarify a path to getting this done.
Ramesh will post in a bit...
Barry
----- 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
_______________________________________________ teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev