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

[John Doyle]

----- "John Verhaeg" <jverhaeg at redhat.com> wrote:

> On Mar 24, 2010, at 4:06 PM, John Doyle wrote:
> 
> > 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?
> 
> 
> 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".
+1
> 
> 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.
Do you think it would be a workable solution to enable a user to configure connections to multiple Teiids, but have only one connection alive at a time?  All the UI would then be synchronized to that Teiid and we could do our 'hidden' work safely.
> 
> 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.

A container DS is not supposed to used outside of the container.  There are ways you can hack access, but it's an anti-pattern.  With the DTP plugins I'm working on the user will be able to configure a DTP connection to the source DBMS and view the data through the same UI that they will use to query Teiid.  I think this is a pretty good solution, and a nice new feature that we'll get for free.

  
> 
> Thoughts?
> 
> Thanks,
> 
> JPAV