3:23 p.m.
Thx John and Dan,
All good questions and all good answers.
Just had a conversation with S&R and they have arrived at a suggested methodology that
seems pretty simple and extensible and should clarify a path to getting this done.
Ramesh will post in a bit...
Barry
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
To: "Daniel Florian" <dflorian(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Friday, March 26, 2010 1:30:41 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
On Mar 26, 2010, at 12:32 PM, Daniel Florian wrote:
I'm still trying to wrap my head around what you guys are proposing. Could you explain
in a step-by-step fashion how you envision this working? Use a Designer scenario something
like this:
1. physical model created via import
2. connector assigned to model
3. user previews model
4. model is changed
5. user previews again
6. user ends Designer session
7. user starts Designer session
8. user previews model
9. model is deleted
1. User creates a model in the workspace
2. We use Teiid preview API to create new preview VDB and add that model's
workspace index to it (potentially asynchronously). I would think the same method that
creates the VDB on the server would also add the index to it passed as a parameter. The
VDB would be named something unique, something like model name + UUID (Not sure which side
would be responsible for creating this name).
3. If it's a virtual model, the preview VDB is updated via the API as dependencies
are added to it (again, possibly async).
4. When the user previews the model, we prompt for connector information, and use one
or more API methods to bind the model to the connector and/or preview. If Teiid
doesn't allow us to do this late binding, we wouldn't be able to do the previous
steps asynchronously.
5. If user previews again without changes, Teiid has to update nothing.
6. If the user makes a change to the model or one of its dependencies, an update
method is called on the API. Note, changes to physical models may affect multiple preview
models (including the preview for the physical model itself).
7. As models are deleted, the preview API would need to be notified. Again, for
physical models this may involve more than one preview VDB.
So, this splits up communication over the wire into smaller units, but doesn't reduce
the overall communication. But we don't have to manage anything locally other than the
mapping between the models and their associated preview VDBs. Regarding the server used,
we could either also prompt the user for this information the first time a model is
previewed (again, preventing async operations earlier in the process), or alternatively we
could have the user choose the server to use for preview when the Teiid connection is
created, requiring less information from the user during the first preview. Presumably,
the user would be able to switch to a different Teiid later, but that would be a pretty
heavyweight operation requiring lots of shuffling on Designer and copying/cleanup wrt the
previous Teiid used for preview.
What would the API calls look like along the way?
Don't know for sure; that's up to Ramesh and his team. But I would assume just
simple things like createPreviewVdb(), vdb.addModel(), vdb.preview(), etc.
Does Designer have a local version of the VDB?
No, that's definitely one of the benefits both to us and the user experience. The
artifacts involved stay hidden to both the user and the Designer, while hopefully
eliminating any confusion to the user as to how this all works under the covers..
Does Designer still convert our indexes to theirs (didn't know we were doing this)?
No, Teiid will do this. We no longer have to worry about the Teiid index format.
Is Designer persisting any data relating to preview (source bindings for instance)?
I'd think not as long as Teiid would persist these preview VDB's, but we'd
probably persist the mapping between workspace models and preview VDBs.
Thanks,
JPAV
_______________________________________________ teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
10:55 p.m.
New subject: Potential Designer Source Bindings Strategy
On Fri, 2010-03-26 at 15:23 -0400, Barry Lafond wrote:
Ramesh will post in a bit...
Sorry guys I out reach for network access..
What we are proposing is a feature where a "single" vdb can be amended
at runtime in Teiid to add additional VDBs to be part of the original
vdb.
For example:
You started with "X.vdb" and has models "a" and "b". You
deployed this
to Teiid.
Then, you deployed another vdb called "Y.vdb" that has model "a",
"c" to
Teiid.
then using a admin method like "mergeMetadataStores('X', 'Y')"
you can
merge X and Y. Considering "X" is parent VDB and "Y" is child, the
models "a" and "c" will be added to the "X". "a"
will replace the old
model in original, "c" will be added as new. Now, vdb "X" has models
"a", "b", "c". If user issues a query against "X",
he can query anything
from models "a", "b", "c". We do assume that models are
unique across
VDBs based on their names, otherwise they get overridden.
In the Designer case, 'X' is preview VDB (may be empty), then we add
*each* model from Designer's workspace as a *individual* VDB into Teiid.
Let's call this for this conversation as "model vdb". We know that model
VDB is not complete on its own, but merged with others it will be. Every
time model is added/modified/deleted the designer will use current admin
methods
deployVDB(vdbName, contents)
undeployVDB(vdbName)
to manage the model vdbs, keeps it in sync with Designer. Then Designer
issues the 'merge' call and builds the preview vdb. Each model vdb
deployed will resemble the contents of regular VDB and has 'vdb.xml' to
define source bindings and model names. Index files supplied can be
Designer's workspace (needs verification) indexes or typed indexed
files. We do not need to add XMI files, other than for FUNCTION models
or XSD or WSDL files. We will also add a flag in the vdb.xml properties
to hide exposing these partial model vdb such that no one can connect to
them and issue queries directly or view them through JOPR. This only for
Designer preview. We will also relax the model validation errors or
incomplete bindings for these model vdbs in Teiid.
This will make us only add one method into admin api and gives us a new
feature. Lot of times our customers stack Teiid on top of Teiid to use
the VDB as another source in second VDB. This makes user to deploy VDB
and create the binding to it, then access the VDB through the binding in
the same or different Teiid instance. All they are looking is sharing of
models. Here using this above technique of combining the two VDBS, we do
not need to create additional bindings, and we can create much efficient
processing plans as we can flatten them if are from single VDB.
So, in a way what we said before sticks upto creating VDB, but create
VDB/per model and merge them on the go. Designer does not need to
maintain any preview vdb. just keep shoving each model as VDB as it
goes. This will not make Teiid keep reloading the vdbs. Only changed
model vdbs get reloaded and merged.
Thoughts? questions?
Ramesh..
4:43 p.m.
New subject: Potential Designer Source Bindings Strategy
Guys,
As a side-note/observation....
Providing Designer a way to manage a VDB and it's contents via Teiid Server, sure
looks an awful Lot like the paradigm that Dimension provided (minus the web-service stuff)
In fact, it provide identical functionality.
Kinda begs the question that JPAV asked on this thread about NOT hiding this VDB from the
user.
If we took it a step futher, couldn't we just treat these VDB's as
"Development" VDB's? Users could create them "specifically", and
name them as they choose. So a DVDB would look slightly different, we could show
"contents" in tree, users could "drag" models into it, etc...?
If a user was satisfied with a Dev VDB, they could promote/publish it and we would do a
full "zip" locally...
Just think out of the box and into an "old" Dimension box.
Barry
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "Barry Lafond" <blafond(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Friday, March 26, 2010 9:55:27 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
On Fri, 2010-03-26 at 15:23 -0400, Barry Lafond wrote:
Ramesh will post in a bit...
Sorry guys I out reach for network access..
What we are proposing is a feature where a "single" vdb can be amended
at runtime in Teiid to add additional VDBs to be part of the original
vdb.
For example:
You started with "X.vdb" and has models "a" and "b". You
deployed this
to Teiid.
Then, you deployed another vdb called "Y.vdb" that has model "a",
"c" to
Teiid.
then using a admin method like "mergeMetadataStores('X', 'Y')"
you can
merge X and Y. Considering "X" is parent VDB and "Y" is child, the
models "a" and "c" will be added to the "X". "a"
will replace the old
model in original, "c" will be added as new. Now, vdb "X" has models
"a", "b", "c". If user issues a query against "X",
he can query anything
from models "a", "b", "c". We do assume that models are
unique across
VDBs based on their names, otherwise they get overridden.
In the Designer case, 'X' is preview VDB (may be empty), then we add
*each* model from Designer's workspace as a *individual* VDB into Teiid.
Let's call this for this conversation as "model vdb". We know that model
VDB is not complete on its own, but merged with others it will be. Every
time model is added/modified/deleted the designer will use current admin
methods
deployVDB(vdbName, contents)
undeployVDB(vdbName)
to manage the model vdbs, keeps it in sync with Designer. Then Designer
issues the 'merge' call and builds the preview vdb. Each model vdb
deployed will resemble the contents of regular VDB and has 'vdb.xml' to
define source bindings and model names. Index files supplied can be
Designer's workspace (needs verification) indexes or typed indexed
files. We do not need to add XMI files, other than for FUNCTION models
or XSD or WSDL files. We will also add a flag in the vdb.xml properties
to hide exposing these partial model vdb such that no one can connect to
them and issue queries directly or view them through JOPR. This only for
Designer preview. We will also relax the model validation errors or
incomplete bindings for these model vdbs in Teiid.
This will make us only add one method into admin api and gives us a new
feature. Lot of times our customers stack Teiid on top of Teiid to use
the VDB as another source in second VDB. This makes user to deploy VDB
and create the binding to it, then access the VDB through the binding in
the same or different Teiid instance. All they are looking is sharing of
models. Here using this above technique of combining the two VDBS, we do
not need to create additional bindings, and we can create much efficient
processing plans as we can flatten them if are from single VDB.
So, in a way what we said before sticks upto creating VDB, but create
VDB/per model and merge them on the go. Designer does not need to
maintain any preview vdb. just keep shoving each model as VDB as it
goes. This will not make Teiid keep reloading the vdbs. Only changed
model vdbs get reloaded and merged.
Thoughts? questions?
Ramesh..
5147
days inactive
5149
days old
teiid-designer-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Barry Lafond -
Ramesh Reddy