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

[Barry Lafond]

Guys, 

As a side-note/observation.... 

Providing Designer a way to manage a VDB and it's contents via Teiid Server, sure looks an awful Lot like the paradigm that Dimension provided (minus the web-service stuff) 

In fact, it provide identical functionality. 

Kinda begs the question that JPAV asked on this thread about NOT hiding this VDB from the user. 

If we took it a step futher, couldn't we just treat these VDB's as "Development" VDB's? Users could create them "specifically", and name them as they choose. So a DVDB would look slightly different, we could show "contents" in tree, users could "drag" models into it, etc...? 

If a user was satisfied with a Dev VDB, they could promote/publish it and we would do a full "zip" locally... 

Just think out of the box and into an "old" Dimension box. 

Barry 

----- Original Message ----- 
From: "Ramesh Reddy" <rareddy at redhat.com> 
To: "Barry Lafond" <blafond at redhat.com> 
Cc: "teiid-designer-dev" <teiid-designer-dev at lists.jboss.org> 
Sent: Friday, March 26, 2010 9:55:27 PM GMT -06:00 US/Canada Central 
Subject: Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy 

On Fri, 2010-03-26 at 15:23 -0400, Barry Lafond wrote: 
> Ramesh will post in a bit... 

Sorry guys I out reach for network access.. 

What we are proposing is a feature where a "single" vdb can be amended 
at runtime in Teiid to add additional VDBs to be part of the original 
vdb. 

For example: 

You started with "X.vdb" and has models "a" and "b". You deployed this 
to Teiid. 

Then, you deployed another vdb called "Y.vdb" that has model "a", "c" to 
Teiid. 

then using a admin method like "mergeMetadataStores('X', 'Y')" you can 
merge X and Y. Considering "X" is parent VDB and "Y" is child, the 
models "a" and "c" will be added to the "X". "a" will replace the old 
model in original, "c" will be added as new. Now, vdb "X" has models 
"a", "b", "c". If user issues a query against "X", he can query anything 
from models "a", "b", "c". We do assume that models are unique across 
VDBs based on their names, otherwise they get overridden. 

In the Designer case, 'X' is preview VDB (may be empty), then we add 
*each* model from Designer's workspace as a *individual* VDB into Teiid. 
Let's call this for this conversation as "model vdb". We know that model 
VDB is not complete on its own, but merged with others it will be. Every 
time model is added/modified/deleted the designer will use current admin 
methods 

deployVDB(vdbName, contents) 
undeployVDB(vdbName) 

to manage the model vdbs, keeps it in sync with Designer. Then Designer 
issues the 'merge' call and builds the preview vdb. Each model vdb 
deployed will resemble the contents of regular VDB and has 'vdb.xml' to 
define source bindings and model names. Index files supplied can be 
Designer's workspace (needs verification) indexes or typed indexed 
files. We do not need to add XMI files, other than for FUNCTION models 
or XSD or WSDL files. We will also add a flag in the vdb.xml properties 
to hide exposing these partial model vdb such that no one can connect to 
them and issue queries directly or view them through JOPR. This only for 
Designer preview. We will also relax the model validation errors or 
incomplete bindings for these model vdbs in Teiid. 

This will make us only add one method into admin api and gives us a new 
feature. Lot of times our customers stack Teiid on top of Teiid to use 
the VDB as another source in second VDB. This makes user to deploy VDB 
and create the binding to it, then access the VDB through the binding in 
the same or different Teiid instance. All they are looking is sharing of 
models. Here using this above technique of combining the two VDBS, we do 
not need to create additional bindings, and we can create much efficient 
processing plans as we can flatten them if are from single VDB. 

So, in a way what we said before sticks upto creating VDB, but create 
VDB/per model and merge them on the go. Designer does not need to 
maintain any preview vdb. just keep shoving each model as VDB as it 
goes. This will not make Teiid keep reloading the vdbs. Only changed 
model vdbs get reloaded and merged. 

Thoughts? questions? 


Ramesh.. 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/teiid-designer-dev/attachments/20100328/038d155a/attachment-0001.html