12:32 p.m.
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
What would the API calls look like along the way? What is done in the Designer along the
way? Does Designer have a local version of the VDB? Does Designer still convert our
indexes to theirs (didn't know we were doing this)? Is Designer persisting any data
relating to preview (source bindings for instance)?
Sorry lots of questions.
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Friday, March 26, 2010 10:27:32 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
Ramesh had an idea yesterday that we discussed offline that at first blush seems to answer
most of this question.
First, to clarify an assumption, it seems preview is the potentially high frequency and
performance concern here. Given that is true, I believe part of the performance concern
is the number of models/indexes in the VDB because of the need to convert our indexes to
their indexes for every one that appears, and simply the size of the indexes being
transmitted over the wire, every time we deploy the VDB to them (Ramesh, correct me if
I've misstated this or missed a concern). Thus, even if we do things like,
a) not include the actual model XMI files,
b) only locally validate the models that have changed, and
c) only include in the VDB the model being previewed,
Teiid has no idea what was "changed from last time" and must process all models
as if new. Using the optimization attempts enumerated above, previewing physical models
isn't much of an issue, but virtual models are still potentially a big problem.
Ramesh's solution to all of this was to provide additional API specifically for
preview. The idea is we'd create a VDB via an API call instead of locally for each
model previewed (or maybe just for virtual models?). As models are added/removed from the
dependencies of the model being previewed, we make appropriate API calls to Teiid, such
that Teiid doesn't have to re-process all of the metadata for stuff that hasn't
changed. So, I'm thinking if we come up with some way to uniquely identify each
"preview VDB", such as model name and UUID (addressing is concerns with a shared
Teiid), we can keep it hidden as previously discussed, maintain its contents
asynchronously as dependencies change, and get pretty close to the same performance we had
previously with an embedded Teiid, from both the Designer's and Teiid's s
viewpoint.
Thoughts?
Thanks,
JPAV
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
1:30 p.m.
New subject: 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
User creates a model in the workspace
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).
If it's a virtual model, the preview VDB is updated via the API as dependencies are
added to it (again, possibly async).
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.
If user previews again without changes, Teiid has to update nothing.
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).
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
5402
days inactive
5402
days old
teiid-designer-dev@lists.jboss.org
1 comments
2 participants
participants (2)
-
Daniel Florian -
John Verhaeg