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