[teiid-designer-dev] Potential Designer Source Bindings Strategy
Ramesh Reddy
rareddy at redhat.com
Fri Mar 26 15:24:53 EDT 2010
On Fri, 2010-03-26 at 10:27 -0500, John Verhaeg wrote:
> Ramesh's solution to all of this was to provide additional API
> specifically for preview.
I am calling it "Preview API" for now. Consider that if this API has
following methods ( !!!these will not be the methods!!!) for
illustration purpose
createVDB(vdbName);
addModel(vdbName, modelName, indexContents, sourceName/jndi)
deleteModel(vdbName, modelName)
> 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?).
Actually for your workspace, no need to do this vdb or model or all
models in a preview query any more. When a model changes/previewed then
you can choose to update *only* the changed models and then issue a
query.
> 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.
correct.
> 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.
no to this. No really need hidden; just keep what you have now. Create
sudo "preview" vdb on server, just update the models as you go. If not,
keep "preview" vdb per/project to minimize size of unnecessary models in
the Teiid.
I hope now you got the concept as to where I am going. In the next post,
I will this concept up a notch to tie into a feature Teiid is also
looking to full fill. So, stay tuned!
More information about the teiid-designer-dev
mailing list