9:32 p.m.
Now I get what you mean by "sandbox." I can't really envision a Designer
user having registered different types of Teiid servers (dev, test, production) within
their Designer instance. Seems like the user would register one or more of the type they
are concerned with (i.e., just test, or just dev, or just production). I can see multiple
Teiids being registered when the Teiids are running different versions for one example. To
mix the type of Teiid seems extremely dangerous to me. You can correct me on this if these
assumption are not valid.
I still like the idea of the hidden VDB unless we get rid of the whole preview idea
altogether (which is not going to happen).
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
To: "Barry Lafond" <blafond(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Thursday, March 25, 2010 2:49:44 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] 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
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
10:30 p.m.
New subject: Potential Designer Source Bindings Strategy
On Mar 25, 2010, at 3:32 PM, Daniel Florian wrote:
Now I get what you mean by "sandbox." I can't really
envision a Designer user having registered different types of Teiid servers (dev, test,
production) within their Designer instance. Seems like the user would register one or more
of the type they are concerned with (i.e., just test, or just dev, or just production). I
can see multiple Teiids being registered when the Teiids are running different versions
for one example. To mix the type of Teiid seems extremely dangerous to me. You can correct
me on this if these assumption are not valid.
I still like the idea of the hidden VDB unless we get rid of the whole preview idea
altogether (which is not going to happen).
I don't know whether this is realistic or not either; just seemed like a possibility.
I just don't like assuming it's not a possibility unless we have some reason to do
so.
Thanks,
JPAV
4:27 p.m.
New subject: Potential Designer Source Bindings Strategy
Ramesh had an idea yesterday that we discussed offline that at first blush seems to answer
most of this question.
First, to clarify an assumption, it seems preview is the potentially high frequency and
performance concern here. Given that is true, I believe part of the performance concern
is the number of models/indexes in the VDB because of the need to convert our indexes to
their indexes for every one that appears, and simply the size of the indexes being
transmitted over the wire, every time we deploy the VDB to them (Ramesh, correct me if
I've misstated this or missed a concern). Thus, even if we do things like,
a) not include the actual model XMI files,
b) only locally validate the models that have changed, and
c) only include in the VDB the model being previewed,
Teiid has no idea what was "changed from last time" and must process all models
as if new. Using the optimization attempts enumerated above, previewing physical models
isn't much of an issue, but virtual models are still potentially a big problem.
Ramesh's solution to all of this was to provide additional API specifically for
preview. The idea is we'd create a VDB via an API call instead of locally for each
model previewed (or maybe just for virtual models?). As models are added/removed from the
dependencies of the model being previewed, we make appropriate API calls to Teiid, such
that Teiid doesn't have to re-process all of the metadata for stuff that hasn't
changed. So, I'm thinking if we come up with some way to uniquely identify each
"preview VDB", such as model name and UUID (addressing is concerns with a shared
Teiid), we can keep it hidden as previously discussed, maintain its contents
asynchronously as dependencies change, and get pretty close to the same performance we had
previously with an embedded Teiid, from both the Designer's and Teiid's s
viewpoint.
Thoughts?
Thanks,
JPAV
8:24 p.m.
New subject: Potential Designer Source Bindings Strategy
On Fri, 2010-03-26 at 10:27 -0500, John Verhaeg wrote:
Ramesh's solution to all of this was to provide additional API
specifically for preview.
I am calling it "Preview API" for now. Consider that if this API has
following methods ( !!!these will not be the methods!!!) for
illustration purpose
createVDB(vdbName);
addModel(vdbName, modelName, indexContents, sourceName/jndi)
deleteModel(vdbName, modelName)
The idea is we'd create a VDB via an API call instead of locally
for
each model previewed (or maybe just for virtual models?).
Actually for your
workspace, no need to do this vdb or model or all
models in a preview query any more. When a model changes/previewed then
you can choose to update *only* the changed models and then issue a
query.
As models are added/removed from the dependencies of the model being
previewed, we make appropriate API calls to Teiid, such that Teiid
doesn't have to re-process all of the metadata for stuff that hasn't
changed.
correct.
So, I'm thinking if we come up with some way to uniquely identify
each
"preview VDB", such as model name and UUID (addressing is concerns
with a shared Teiid), we can keep it hidden as previously discussed,
maintain its contents asynchronously as dependencies change, and get
pretty close to the same performance we had previously with an
embedded Teiid, from both the Designer's and Teiid's s viewpoint.
no to
this. No really need hidden; just keep what you have now. Create
sudo "preview" vdb on server, just update the models as you go. If not,
keep "preview" vdb per/project to minimize size of unnecessary models in
the Teiid.
I hope now you got the concept as to where I am going. In the next post,
I will this concept up a notch to tie into a feature Teiid is also
looking to full fill. So, stay tuned!
9:02 p.m.
New subject: Potential Designer Source Bindings Strategy
On Mar 26, 2010, at 2:24 PM, Ramesh Reddy wrote:
I am calling it "Preview API" for now. Consider that if
this API has
following methods ( !!!these will not be the methods!!!) for
illustration purpose
createVDB(vdbName);
addModel(vdbName, modelName, indexContents, sourceName/jndi)
deleteModel(vdbName, modelName)
How would we update a model?
Actually for your workspace, no need to do this vdb or model or all
models in a preview query any more. When a model changes/previewed then
you can choose to update *only* the changed models and then issue a
query.
I was trying to reduce the number of models we sent over the wire, assuming several in the
workspace would never be previewed during a session, but maybe your approach, or perhaps a
per-project approach, is better just to reduce the number of communications required.
no to this. No really need hidden; just keep what you have now.
Create
sudo "preview" vdb on server, just update the models as you go. If not,
keep "preview" vdb per/project to minimize size of unnecessary models in
the Teiid.
"No" to what - the naming? If so, yes, we'll name them. But we'd still
want the preview VDBs hidden from the user.
Thanks,
JPAV
9:19 p.m.
New subject: Potential Designer Source Bindings Strategy
Guys,
Ramesh will propose something that should clarify some of this.
Note that for "preview VDB" we will NOT have to stream over any XMI, only
Indexes & XML
Barry
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
To: "Ramesh Reddy" <rareddy(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Friday, March 26, 2010 3:02:39 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
On Mar 26, 2010, at 2:24 PM, Ramesh Reddy wrote:
I am calling it "Preview API" for now. Consider that if
this API has
following methods ( !!!these will not be the methods!!!) for
illustration purpose
createVDB(vdbName);
addModel(vdbName, modelName, indexContents, sourceName/jndi)
deleteModel(vdbName, modelName)
How would we update a model?
Actually for your workspace, no need to do this vdb or model or all
models in a preview query any more. When a model changes/previewed then
you can choose to update *only* the changed models and then issue a
query.
I was trying to reduce the number of models we sent over the wire, assuming several in the
workspace would never be previewed during a session, but maybe your approach, or perhaps a
per-project approach, is better just to reduce the number of communications required.
no to this. No really need hidden; just keep what you have now.
Create
sudo "preview" vdb on server, just update the models as you go. If not,
keep "preview" vdb per/project to minimize size of unnecessary models in
the Teiid.
"No" to what - the naming? If so, yes, we'll name them. But we'd still
want the preview VDBs hidden from the user.
Thanks,
JPAV
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
5149
days inactive
5150
days old
teiid-designer-dev@lists.jboss.org
5 comments
4 participants
participants (4)
-
Barry Lafond -
Daniel Florian -
John Verhaeg -
Ramesh Reddy