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..