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

[Barry Lafond]

I like this simplified concept... realizing it adds complexity to Teiid. 

>From a broader perspective, though, it could provide more opportunities for "other tooling" options for "Preview" functionality. (i.e. flexibility) 

Barry 

----- 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/teiid-designer-dev/attachments/20100326/b2012178/attachment-0001.html