Thx John and Dan,

All good questions and all good answers.

Just had a conversation with S&R and they have arrived at a suggested methodology that seems pretty simple and extensible and should clarify a path to getting this done.

Ramesh will post in a bit...

Barry

----- Original Message -----
From: "John Verhaeg" <jverhaeg@redhat.com>
To: "Daniel Florian" <dflorian@redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev@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




_______________________________________________ teiid-designer-dev mailing list teiid-designer-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-designer-dev