Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
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