----- "John Verhaeg" <jverhaeg(a)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