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
9:16 a.m.
New subject: Potential Designer Source Bindings Strategy
----- "Barry Lafond" <blafond(a)redhat.com> 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?
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.
This occurred to me the other day, and I forgot to ask. I don't think they use
the models and we should not put anything in there that's not needed. I know that
VDB's are shipped around as a shared project (in support), unzipped and used to dubug
issues, but there is another artifact for this. Zip up the project and use that.
~jd
2:54 p.m.
New subject: Potential Designer Source Bindings Strategy
On Mar 25, 2010, at 9:16 AM, John Doyle wrote:
This occurred to me the other day, and I forgot to ask. I don't
think they use the models and we should not put anything in there that's not needed.
I know that VDB's are shipped around as a shared project (in support), unzipped and
used to dubug issues, but there is another artifact for this. Zip up the project and use
that.
+1
Thanks,
JPAV
10:27 a.m.
New subject: Potential Designer Source Bindings Strategy
On Thu, 2010-03-25 at 09:51 -0400, Barry Lafond 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?
Although, this is simplest to implement worst performing IMO. If we can
reduce the number of models that may work! But just think of a worksapce
with 10 different VDBs and each of them have 3 models, that is 30 models
to update. Just not going to scale.
I do like the concept of a preview vdb/per project. I never understood
the sharing of models across the projects. Any way we will not cross the
project boundaries for preview of data (I think). This is the minimum we
have to do use preview on this model. However there is still a risk of
single project with tens of models.
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.
No, the index files are the
only ones we look at. I am 99% sure we can
work with workspace index files Vs VDB index files. I am glad to test if
you can provide me a sample.
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.
Once we have decided how we going to do this, I am fine with working out
any reasonable approaches that deviates from the current deployment
model for preview purposes.
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.
Yes, there are exports for VDB, connector bindings and types.
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 am not sure why you guys are hung up on multiple Teiid instance
usecase. This is not the scenario 90% of the times. IMO, preview should
be done from single Teiid instance, preferably that is local. For the
execution of VDB in DTP you can connect to any Teiid instance of your
choice. This makes things lot simpler!
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.
I see not much value; source queries are sent directly to source
through
Teiid. It would be no different, unless you are letting users type the
SQL, in which case they can use certain functions that are not supported
by the source and evaluated by the Teiid. We do not let uses type in SQL
for preview, so no issue. They could always use DTP or Squirrel to do
that.
3:05 p.m.
New subject: Potential Designer Source Bindings Strategy
On Mar 25, 2010, at 10:27 AM, Ramesh Reddy wrote:
I am not sure why you guys are hung up on multiple Teiid instance
usecase. This is not the scenario 90% of the times. IMO, preview should
be done from single Teiid instance, preferably that is local. For the
execution of VDB in DTP you can connect to any Teiid instance of your
choice. This makes things lot simpler!
I think all of us are also envisioning the "normal" use case to involve only one
Teiid for preview, but at the same time I see no reason to enforce this as a rule. The
only extra complexity involved in allowing for more than one is if we're doing things
automatically using hidden VDBs, especially if the preview Teiid is being shared amongst
several users, which we've been told is a very likely case. That's a good part of
the reason I'm suggesting we eliminate the idea of having anything hidden.
I see not much value; source queries are sent directly to source
through
Teiid. It would be no different, unless you are letting users type the
SQL, in which case they can use certain functions that are not supported
by the source and evaluated by the Teiid. We do not let uses type in SQL
for preview, so no issue. They could always use DTP or Squirrel to do
that.
Ah, you're correct Ramesh, I'm mixing test execution with preview. My bad, never
mind.
Thanks,
JPAV
3:46 p.m.
New subject: Potential Designer Source Bindings Strategy
On Thu, 2010-03-25 at 15:05 -0500, John Verhaeg wrote:
especially if the preview Teiid is being shared amongst several
users,
which we've been told is a very likely case. That's a good part of
the reason I'm suggesting we eliminate the idea of having anything
hidden.
Wow! that is new use case. I would say the only level you share is at
VDB. If we consider preview as state of your work space this should not
be shared. Are envisioning two people hacking at the same VDB
simultaneously? Bad!
Ramesh..
3:51 p.m.
New subject: Potential Designer Source Bindings Strategy
may be I read your posting wrong on this! apologies.
On Thu, 2010-03-25 at 15:46 -0500, Ramesh Reddy wrote:
On Thu, 2010-03-25 at 15:05 -0500, John Verhaeg wrote:
> especially if the preview Teiid is being shared amongst several users,
> which we've been told is a very likely case. That's a good part of
> the reason I'm suggesting we eliminate the idea of having anything
> hidden.
Wow! that is new use case. I would say the only level you share is at
VDB. If we consider preview as state of your work space this should not
be shared. Are envisioning two people hacking at the same VDB
simultaneously? Bad!
Ramesh..
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
4:27 p.m.
New subject: Potential Designer Source Bindings Strategy
On Mar 25, 2010, at 3:46 PM, Ramesh Reddy wrote:
Wow! that is new use case. I would say the only level you share is
at
VDB. If we consider preview as state of your work space this should not
be shared. Are envisioning two people hacking at the same VDB
simultaneously? Bad!
No, not at all. We'd have to somehow name these hidden VDBs uniquely so that
doesn't happen. Again, part of the reason why this is starting to look like a hack.
Thanks,
JPAV
2:49 p.m.
New subject: Potential Designer Source Bindings Strategy
On Mar 25, 2010, at 8:51 AM, Barry Lafond wrote:
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.
I'm not trying to introduce a new concept here by talking about a "sandbox"
Teiid. The fact that we're assuming the user can do things like preview against some
Teiid automatically makes that Teiid a "sandbox". In other words, this
isn't a production Teiid in any way that's administered by some IT group with a
bunch of rules concerning who, when, and what can be deployed.
All I was saying is that the user has to choose which of the potentially many Teiids they
have configured in Designer to treat as a sandbox (i.e., use for preview and test
execution). We could allow them to choose more than one, but we'd certainly always
"default" to just one in particular I'd expect (the first or last one setup
for preview/execution). The user may also have connections to other Teiids that they
aren't allowed to "play" with, such as testing servers or even productions
servers, for which maybe the only thing they can do is retrieve connector types or import
VDBs for instance.
Thanks,
JPAV
5672
days inactive
5672
days old
teiid-designer-dev@lists.jboss.org
8 comments
4 participants
participants (4)
-
Barry Lafond -
John Doyle -
John Verhaeg -
Ramesh Reddy