8:51 a.m.
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?
A) I too am concerned with performance. One thing Jacobs asked me yesterday was whether we
needed to actually put the models in the VDB. We have to work with Ramesh on this, but my
understanding is they don't use the models. To execute queries, the connector info and
"query metadata" needs to be present and that means indexes to view models and
their associated/dependent source models.
RAMESH TODO: Clarify "required" VDB content.
B) In discussions with Ramesh a couple of weeks ago, he was receptive to providing hooks
for our "hidden" VDB concept, so I'm hoping there is some wiggle room here.
RAMESH TODO: Clarify ability to manage a special/simplified VDB.
C) There are "export" methods in Teiid API that I'm guessing will allow us
to just copy/paste connectors between Teiids. If not, we have to do a little more work,
but its doable.
D) I'm still struggling with the concept of a "SandBox" Teiid. If a user has
multiple Teiids and there are Connector Types that don't reside on ALL Teiids, then as
a user, I'd have to work a little harder, switching between "SandBoxes" as I
try to create source models, wire them to different Teiids for the purpose of
"Preview Data ". I think the Hidden VDB concept is still the cleanest paradigm.
User need only Import/Create Sources. Create View models. Assign/change/swap (DND) models
to connectors deployed on any Teiid and the Preview Data just works. I can also have a
source model bound to connectors on multiple Teiids. As long as we decorate (via Model
Explorer AND Execution/Connectors/Teiid View) this connectivity we should be good to go.
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.
E) As long as we're successful in replacing our JDBC calls at import time with
DTP's version, I think we should be able to preview the actual source.
Barry
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
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev