> 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@redhat.com>
> To: "Barry Lafond" <blafond@redhat.com>
> Cc: "teiid-designer-dev" <teiid-designer-dev@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..
>
>
>
>