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

[Daniel Florian]

Thanks that clears a lot up. I like the approach. A few more questions though:

- Don't really see how you can create the preview VDB right after creating the model. How do you know what Teiid server the connector will come from? Seems like this will have to wait until the connector is chosen/created. Unless you are assuming there is one and only one Teiid server used to preview. Also would assume then that if the user has not designated any servers then preview would be disabled.

- Don't understand why one and only one Teiid server has to be picked for preview. Why can't you preview a model on a Teiid server running say Teiid version N. And also preview the same model using a different source binding to a different Teiid server that is running version N+1. Not sure how if this is a valuable use case or if there are any valuable use cases but it doesn't make sense to me to limit them to only one.

- Doesn't seem like we currently can get workspace indexes for just one model or for a set of selected models. This will be new functionality right?

- Don't think Teiid would care about the VDB name (correct me if I'm wrong). We should come up with the names and pass in via API. And since we'll have a programmatic way of creating the names we wouldn't need to keep a mapping.

Cheers

----- Original Message -----
From: "John Verhaeg" <jverhaeg at redhat.com>
To: "Daniel Florian" <dflorian at redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev at lists.jboss.org>
Sent: Friday, March 26, 2010 1:30:41 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy



On Mar 26, 2010, at 12:32 PM, Daniel Florian wrote: 



I'm still trying to wrap my head around what you guys are proposing. Could you explain in a step-by-step fashion how you envision this working? Use a Designer scenario something like this: 

1. physical model created via import 
2. connector assigned to model 
3. user previews model 
4. model is changed 
5. user previews again 
6. user ends Designer session 
7. user starts Designer session 
8. user previews model 
9. model is deleted 



    1. User creates a model in the workspace 
    2. We use Teiid preview API to create new preview VDB and add that model's workspace index to it (potentially asynchronously). I would think the same method that creates the VDB on the server would also add the index to it passed as a parameter. The VDB would be named something unique, something like model name + UUID (Not sure which side would be responsible for creating this name). 
    3. If it's a virtual model, the preview VDB is updated via the API as dependencies are added to it (again, possibly async). 
    4. When the user previews the model, we prompt for connector information, and use one or more API methods to bind the model to the connector and/or preview. If Teiid doesn't allow us to do this late binding, we wouldn't be able to do the previous steps asynchronously. 
    5. If user previews again without changes, Teiid has to update nothing. 
    6. If the user makes a change to the model or one of its dependencies, an update method is called on the API. Note, changes to physical models may affect multiple preview models (including the preview for the physical model itself). 
    7. As models are deleted, the preview API would need to be notified. Again, for physical models this may involve more than one preview VDB. 



So, this splits up communication over the wire into smaller units, but doesn't reduce the overall communication. But we don't have to manage anything locally other than the mapping between the models and their associated preview VDBs. Regarding the server used, we could either also prompt the user for this information the first time a model is previewed (again, preventing async operations earlier in the process), or alternatively we could have the user choose the server to use for preview when the Teiid connection is created, requiring less information from the user during the first preview. Presumably, the user would be able to switch to a different Teiid later, but that would be a pretty heavyweight operation requiring lots of shuffling on Designer and copying/cleanup wrt the previous Teiid used for preview. 





What would the API calls look like along the way? 

Don't know for sure; that's up to Ramesh and his team. But I would assume just simple things like createPreviewVdb(), vdb.addModel(), vdb.preview(), etc. 




Does Designer have a local version of the VDB? 

No, that's definitely one of the benefits both to us and the user experience. The artifacts involved stay hidden to both the user and the Designer, while hopefully eliminating any confusion to the user as to how this all works under the covers.. 




Does Designer still convert our indexes to theirs (didn't know we were doing this)? 

No, Teiid will do this. We no longer have to worry about the Teiid index format. 




Is Designer persisting any data relating to preview (source bindings for instance)? 


I'd think not as long as Teiid would persist these preview VDB's, but we'd probably persist the mapping between workspace models and preview VDBs. 



Thanks, 


JPAV