6:49 p.m.
As I said before, I'm generally not in favor of hiding anything, but while we're
thinking out of the box, and a hidden VDB is on the table, we could go in the other
direction. Why not use a hidden VDB to preview ( I imagine this is what happens for a lot
of targets when using Run As...) and standard eclipse Export paradigm to create the
'real' VDB. Get rid of the entire user gesture for New->VDB and the appearance
of a VDB in the project view.
This comes at a cost in flexibility. As implemented today a user can create multiple
different VDBs from a single Model Project, and in the implementation I'm describing
Model Project = VDB. In that sense I don't really conder that we're hiding
anything if we did it this way. I don't know if multiple VDBs from a single project is
a use case anybody is interested in.
I didn't touch Dimension outside of all hands testing so long ago, so I don't
really know if this is the opposite of what Barry described below or not. Dimension forced
explicit VDB creation at the outset????
~jd
----- "Barry Lafond" <blafond(a)redhat.com> wrote:
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..
_______________________________________________ teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
10:40 p.m.
New subject: Potential Designer Source Bindings Strategy
On Mar 29, 2010, at 11:49 AM, John Doyle wrote:
I didn't touch Dimension outside of all hands testing so long
ago, so I don't really know if this is the opposite of what Barry described below or
not. Dimension forced explicit VDB creation at the outset????
Yes, the was exactly the main concept Dimension introduced. The entire
"workspace" represented a single VDB. There was no concept of
"project". All model creation/editing/etc. occurred within the context of the
VDB. Thus, the idea of having multiple VDBs that spanned a set of models, or thinking of
it from a different perspective, a "workspace" where a single model could exist
within multiple VDBs, didn't exist. Simpler mental model, less flexibility, and
cheaper cost.
As I said before, I'm generally not in favor of hiding anything,
but while we're thinking out of the box, and a hidden VDB is on the table, we could go
in the other direction. Why not use a hidden VDB to preview ( I imagine this is what
happens for a lot of targets when using Run As...) and standard eclipse Export paradigm
to create the 'real' VDB. Get rid of the entire user gesture for New->VDB and
the appearance of a VDB in the project view.
This comes at a cost in flexibility. As implemented today a user can create multiple
different VDBs from a single Model Project, and in the implementation I'm describing
Model Project = VDB. In that sense I don't really conder that we're hiding
anything if we did it this way. I don't know if multiple VDBs from a single project
is a use case anybody is interested in.
I agree with the direction you're suggesting here, but it's probably going to be
much more than we can bite off for this next release. Talking to the GSS guys, it's a
pretty common use case for a customer to want to share a model across multiple VDBs, so I
think we'd also have to use Eclipse links to share models across projects so that
changes may be kept in sync. This would visually look like Dimension, but add one extra
layer to allow multiple VDBs in a workspace.
Regarding just preview, I think starting out we need to keep things as easy for the user
as possible and add more advanced functionality only when asked for it. That said, it
seems like the simplest, easiest user experience would entail using Ramesh's API
additions and a single Teiid instance having workspace-wide scope regarding preview so the
user doesn't ever have to worry about it. Assuming a Teiid is bundled and configured
with the tooling, we would automatically make that the preview instance, avoiding even the
necessity of any first-time setup by the user.
Thanks,
JPAV
5:55 p.m.
New subject: Potential Designer Source Bindings Strategy
----- "John Verhaeg" <jverhaeg(a)redhat.com> wrote:
I agree with the direction you're suggesting here, but it's probably going to be
much more than we can bite off for this next release.
My thoughts as well.
I think we'd also have to use Eclipse links to share models across projects so that
changes may be kept in sync.
Do you have a link with info about eclipse links? All I could find was the links that
enable you to have your plug-ins outside of your install dir.
Regarding just preview, I think starting out we need to keep
things as easy for the user as possible and add more advanced functionality only when
asked for it. That said, it seems like the simplest, easiest user experience would entail
using Ramesh's API additions and a single Teiid instance having workspace-wide scope
regarding preview so the user doesn't ever have to worry about it. Assuming a Teiid is
bundled and configured with the tooling, we would automatically make that the preview
instance, avoiding even the necessity of any first-time setup by the user.
+1
Thanks,
JPAV
> _______________________________________________
teiid-designer-dev mailing list teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
5413
days inactive
5414
days old
teiid-designer-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
John Doyle -
John Verhaeg