<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Verdana; font-size: 12pt; color: #000000'>Guys,<br><br>As a side-note/observation....<br><br>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)<br><br>In fact, it provide identical functionality.<br><br>Kinda begs the question that JPAV asked on this thread about NOT hiding this VDB from the user.<br><br>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...?<br><br>If a user was satisfied with a Dev VDB, they could promote/publish it and we would do a full "zip" locally...<br><br>Just think out of the box and into an "old" Dimension box.<br><br>Barry<br><br>----- Original Message -----<br>From: "Ramesh Reddy" <rareddy@redhat.com><br>To: "Barry Lafond" <blafond@redhat.com><br>Cc: "teiid-designer-dev" <teiid-designer-dev@lists.jboss.org><br>Sent: Friday, March 26, 2010 9:55:27 PM GMT -06:00 US/Canada Central<br>Subject: Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy<br><br>On Fri, 2010-03-26 at 15:23 -0400, Barry Lafond wrote: <br>> Ramesh will post in a bit...<br><br>Sorry guys I out reach for network access..<br><br>What we are proposing is a feature where a "single" vdb can be amended<br>at runtime in Teiid to add additional VDBs to be part of the original<br>vdb. <br><br>For example: <br><br>You started with "X.vdb" and has models "a" and "b". You deployed this<br>to Teiid.<br><br>Then, you deployed another vdb called "Y.vdb" that has model "a", "c" to<br>Teiid.<br><br>then using a admin method like "mergeMetadataStores('X', 'Y')" you can<br>merge X and Y. Considering "X" is parent VDB and "Y" is child, the<br>models "a" and "c" will be added to the "X". "a" will replace the old<br>model in original, "c" will be added as new. Now, vdb "X" has models<br>"a", "b", "c". If user issues a query against "X", he can query anything<br>from models "a", "b", "c". We do assume that models are unique across<br>VDBs based on their names, otherwise they get overridden.<br><br>In the Designer case, 'X' is preview VDB (may be empty), then we add<br>*each* model from Designer's workspace as a *individual* VDB into Teiid.<br>Let's call this for this conversation as "model vdb". We know that model<br>VDB is not complete on its own, but merged with others it will be. Every<br>time model is added/modified/deleted the designer will use current admin<br>methods<br><br>deployVDB(vdbName, contents)<br>undeployVDB(vdbName)<br><br>to manage the model vdbs, keeps it in sync with Designer. Then Designer<br>issues the 'merge' call and builds the preview vdb. Each model vdb<br>deployed will resemble the contents of regular VDB and has 'vdb.xml' to<br>define source bindings and model names. Index files supplied can be<br>Designer's workspace (needs verification) indexes or typed indexed<br>files. We do not need to add XMI files, other than for FUNCTION models<br>or XSD or WSDL files. We will also add a flag in the vdb.xml properties<br>to hide exposing these partial model vdb such that no one can connect to<br>them and issue queries directly or view them through JOPR. This only for<br>Designer preview. We will also relax the model validation errors or<br>incomplete bindings for these model vdbs in Teiid.<br><br>This will make us only add one method into admin api and gives us a new<br>feature. Lot of times our customers stack Teiid on top of Teiid to use<br>the VDB as another source in second VDB. This makes user to deploy VDB<br>and create the binding to it, then access the VDB through the binding in<br>the same or different Teiid instance. All they are looking is sharing of<br>models. Here using this above technique of combining the two VDBS, we do<br>not need to create additional bindings, and we can create much efficient<br>processing plans as we can flatten them if are from single VDB.<br><br>So, in a way what we said before sticks upto creating VDB, but create<br>VDB/per model and merge them on the go. Designer does not need to<br>maintain any preview vdb. just keep shoving each model as VDB as it<br>goes. This will not make Teiid keep reloading the vdbs. Only changed<br>model vdbs get reloaded and merged.<br><br>Thoughts? questions?<br><br><br>Ramesh..<br><br><br><br></div></body></html>