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

[John Verhaeg]

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

> - Don't really see how you can create the preview VDB right after creating the model.

It depends.  We could either not create it right away and wait until prompting the user during preview, or we could ask the user which Teiid instance to use for preview when the Teiid connection is created, allowing for a "modal" scenario where only one Teiid at a time is acting as the preview engine (John Doyle talked suggested this earlier).

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

Either the "active" Teiid chosen or the user would choose the same time they choose the connector, just as described above.

> Unless you are assuming there is one and only one Teiid server used to preview.

Yes, that was an assumption.  If we allow for multiple Teiids to be involved, then we'd have to defer until preview, which would also prevent the up-front creation of the preview VDB.

> Also would assume then that if the user has not designated any servers then preview would be disabled.

If no Teiid connection existed, we'd either disable the action or send them to the connection creation view first when preview is selected.  Once a connection exists, we'd prompt if no Teiid has yet been chosen for preview, but selecting a Teiid as a preview engine would be part of the process when creating a Teiid connection.

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

As explained above, we wouldn't have to limit it.  We could either allow for models tied to multiple Teiids simultaneously, or we could use the "modal" model I described above.  The modal approach reduces the number of things the user has to select over and over when previewing.  It doesn't prevent the use of more than one Teiid, just requires a workspace-level move.

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

My understanding is that's exactly what we do now.  Our internal indexes are per model, so, no, this won't be new functionality.  Only the Teiid indexes are organized by component (tables, columns, etc.).  Correct me if I'm wrong.

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

Right.  I didn't think this fully through.  Since we'd only be passing the indexes, not the models, to Teiid, we'd always need to provide the name.

> And since we'll have a programmatic way of creating the names we wouldn't need to keep a mapping.

The mapping is so we know when VDB needs to be created on Teiid vs. updated, but I guess that depends on how "smart" the preview API will be.  It also would be to keep track of dependencies that end up in one or more preview VDBs, but here also I guess we wouldn't have to persist this; we could walk the dependencies during startup and just create an in-memory mapping.

Thanks,

JPAV