<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'><style>p { margin: 0; }</style><div style="font-family: Times New Roman; font-size: 12pt; color: rgb(0, 0, 0);">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.<br><br>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.<br><br>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????<br><br>~jd<br>----- "Barry Lafond" <blafond@redhat.com> wrote:
<br>> <style>p { margin: 0; }</style><div style="font-family: Verdana; font-size: 12pt; color: rgb(0, 0, 0);">> 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><br>> _______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
</div></div></body></html>