[teiid-designer-dev] Potential Designer Source Bindings Strategy

[Daniel Florian]

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 at redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev at 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 at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev