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

[John Doyle]

As I said before, I'm generally not in favor of hiding anything, but while we're thinking out of the box, and a hidden VDB is on the table, we could go in the other direction. Why not use a hidden VDB to preview ( I imagine this is what happens for a lot of targets when using Run As...) and standard eclipse Export paradigm to create the 'real' VDB. Get rid of the entire user gesture for New->VDB and the appearance of a VDB in the project view. 

This comes at a cost in flexibility. As implemented today a user can create multiple different VDBs from a single Model Project, and in the implementation I'm describing Model Project = VDB. In that sense I don't really conder that we're hiding anything if we did it this way. I don't know if multiple VDBs from a single project is a use case anybody is interested in. 

I didn't touch Dimension outside of all hands testing so long ago, so I don't really know if this is the opposite of what Barry described below or not. Dimension forced explicit VDB creation at the outset???? 

~jd 
----- "Barry Lafond" <blafond at redhat.com> wrote: 
> 
> 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.. 
> 
> 
> 
> 
> _______________________________________________ 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/20100329/7572eecb/attachment-0001.html