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

[Barry Lafond]

> Just an initial thought with only one read through. Would it be a good idea to implement "entire redeploy' strategy described in the last paragraph to see if there is a performance issue? 


A) I too am concerned with performance. One thing Jacobs asked me yesterday was whether we needed to actually put the models in the VDB. We have to work with Ramesh on this, but my understanding is they don't use the models. To execute queries, the connector info and "query metadata" needs to be present and that means indexes to view models and their associated/dependent source models. 


RAMESH TODO: Clarify "required" VDB content. 

B) In discussions with Ramesh a couple of weeks ago, he was receptive to providing hooks for our "hidden" VDB concept, so I'm hoping there is some wiggle room here. 


RAMESH TODO: Clarify ability to manage a special/simplified VDB. 

C) There are "export" methods in Teiid API that I'm guessing will allow us to just copy/paste connectors between Teiids. If not, we have to do a little more work, but its doable. 

D) I'm still struggling with the concept of a "SandBox" Teiid. If a user has multiple Teiids and there are Connector Types that don't reside on ALL Teiids, then as a user, I'd have to work a little harder, switching between "SandBoxes" as I try to create source models, wire them to different Teiids for the purpose of "Preview Data ". I think the Hidden VDB concept is still the cleanest paradigm. User need only Import/Create Sources. Create View models. Assign/change/swap (DND) models to connectors deployed on any Teiid and the Preview Data just works. I can also have a source model bound to connectors on multiple Teiids. As long as we decorate (via Model Explorer AND Execution/Connectors/Teiid View) this connectivity we should be good to go. 

> Lastly, I was also thinking maybe for physical models only, we could additionally include the option to preview the import/actual source to help verify against results coming from Teiid. 

E) As long as we're successful in replacing our JDBC calls at import time with DTP's version, I think we should be able to preview the actual source. 

Barry 



That would make sense to me. 

> For each Teiid server registered within the Designer, an associated 
> VDB will be created. These VDBs will be hidden from the user and will 
> not appear in their Eclipse workspace. These VDBs will be deployed 
> (unbeknownst to the user) to their associated Teiid server and will 
> contain all the models from the workspace that have source bindings 
> with connectors installed on that server. These local, hidden VDBs and 
> their associated deployed VDB must stay in sync. The class in charge 
> of this will be the SourceBindingsManager (SBM). 


Another thing I'm concerned about is the "for each server" clauses that appear throughout. First, just a clarification issue - to avoid confusion with the JBoss container (AS/EAP), I'd propose that we get used to calling the Teiid runtime engine just "Teiid". 

Secondly, we're assuming the user has an available "sandbox" Teiid available to which they're allowed to deploy connectors and VDBs that they're testing, presumably the one bundled with JBT/JBDS, knowing this assumption is a bit tenuous. Making that same assumption for all Teiids configured seems to be reaching too far; we probably need the user to pick which Teiid is their sandbox instance, and use that consistently unless they explicitly direct us to use another one. 

Thirdly, considering the user really needs to provide us not only the Teiid to which we'll deploy these hidden workspace VDBs, but also must only use connectors available on that particular Teiid (or somehow auto-copy connectors from other Teiid instances to the sandbox Teiid), the potential for confusion to the user as to what we're trying to accomplish seems high. The only thing they wouldn't be doing beyond a "normal" use of Designer is creating the hidden VDB. I'm worried this is starting to look like much more of a hack that it first appeared. What I'm now wondering - and I haven't digested this enough myself yet - is whether we should just punt the whole hidden VDB idea, and make the user create one in all cases. I'm thinking maybe the only real issue here is when they right-click on a model to preview, for instance, that we then ask them for the name of a VDB that we create on-the-fly containing the model being previewed and, in the case of a virtual model, any of! 
its dependencies. We, of course, would attempt to have good defaults for the sandbox Teiid, VDB name, connectors, etc. I'm thinking that if we manage the relationships between the workspace models and their associated VDBs, the user could still drive the whole experience of preview/execution from the workspace, and we'd just do some simple, more intuitive things like auto-synchronizing the VDB containing the model(s) being previewed/executed. 

Lastly, I was also thinking maybe for physical models only, we could additionally include the option to preview the import/actual source to help verify against results coming from Teiid. 

Thoughts? 

Thanks, 

JPAV 




_______________________________________________ 
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/20100325/8b0fb57f/attachment-0001.html