Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
by Steven Hawkins
Is there any consensus here? Mike, Ken?
As I see it:
Option 1: get rid of the version concept altogether and possibly add a rename or copy vdb operation.
Option 2: retain the version concept along with the active default designation. However setting the version will be a design time responsibility and file drop deployments will require different vdb file names for different versions.
Option 3: ?
And regardless of the scenario, deployers will need to ensure that only truly active vdbs are in an active state or suffer the memory/load costs.
----- Original Message -----
From: "Larry O'Leary" <loleary(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>, "John Verhaeg" <jverhaeg(a)redhat.com>
Sent: Thursday, February 18, 2010 4:13:03 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
On Thu, 2010-02-18 at 15:43 -0500, Steven Hawkins wrote:
> At first glance in the scenario you list below, there's no need to
> even bother with the promotion concept. You would just install the
> new version (with a new name) and let apps point over to it as they
> are ready.
Well, except for the fact that the clients do not want to change their
connection properties. In other words, whatever the business as a whole
deems as the latest and greatest, they are fine with. It is just that
there is normally some stragglers that do things their way and disregard
the business decision. In these cases, these stragglers would be
responsible for updating their client connection properties to point to
the renamed (previous version) VDB. Must like in legacy, they would
update their connection properties to point to the old version.
> To achieve the flow your suggesting without versioning would actually
> require an extra step. Prior to promoting the next version, you would
> need to deploy a duplicate of the current version with a new name.
> Then the small set of apps not ready for the update would need to have
> their connections pointed to the copy. Then you could safely promote
> the next version without interrupting the lagging apps.
Right. In this scenario the new VDB would get the name of the old VDB
so that client apps that were following the business decision would not
need to make a change to get the newer VDB. And the lagging users would
update their clients to point to the renamed VDB.
I am not familiar with how we are packaging and naming VDBs to achieve
this but in my opinion, making this a manual process seems logical and
there would be no need for the system to automatically keep track of
things.
Furthermore, the functionality of "active-default" can be achieved the
same way. Just make the active-default or latest version a base name.
MyCoolSource.vdb. When a new version is available for integration
testing but you are not ready to promote it to the "active-default" or
"latest-version", deploy it as MyCoolSource_NextGen.vdb. In this case,
users who want to use the NextGen version would simply change their
client app to point to MyCoolSource_NextGen.vdb and everyone else will
continue to use the "active-default" of MyCoolSource.vdb.
When you are ready to move the "active-default" to the contents of
MyCoolSource_NextGen.vdb then you simply copy MyCoolSource.vdb to
MyCoolSource_OldGen.vdb, copy MyCoolSource_NextGen.vdb to
MyCoolSource.vdb and voila. The only downside here is that
MyCoolSource.vdb and MyCoolSource_NextGen.vdb are duplicates but I
really don't see this as a problem.
The naming convention would be up to business rules and we might want to
make some kind of best practice suggestions to make this manageable but
concept could be just as easily accomplished with version numbers in the
name:
MyCoolSource_v1.vdb
MyCoolSource_v2.vdb
MyCoolSource_v3.vdb
And to achieve "active-default" or "latest-version" you would use
MyCoolSource.vdb -> MyCoolSource_v3.vdb as a symbolic link or copy of
the version you wanted to use.
Of course, this logic all falls apart if the VDB actually contains a
descriptor that defines its name to the system in which case the process
is the same but a bit more complicated because you wouldn't be able to
simply copy/symlink.
> ----- Original Message -----
> From: "Larry O'Leary" <loleary(a)redhat.com>
> To: "John Verhaeg" <jverhaeg(a)redhat.com>
> Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Wednesday, February 17, 2010 11:38:00 AM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-designer-dev] [teiid-dev] VDB Versioning Feature
>
> On Wed, 2010-02-17 at 11:27 -0600, John Verhaeg wrote:
> > On Feb 17, 2010, at 10:44 AM, Larry O'Leary wrote:
> >
> > > Well there are two possibilities here. One is that there is a
> > > roll-back. The other is that a new version of a VDB has been chosen as
> > > the default but some of the organization is not ready to use the newer
> > > version. In which case they would modify their clients to use the
> > > previous version until they are ready to use the new one.
> > >
> > > So, in the "roll-back" scenario, the change is transparent to the
> > > clients while in the "not-ready-to-upgrade" scenario the administrative
> > > change is placed on the client. These are the two cases we have with
> > > legacy customers.
> >
> > Maybe I'm misunderstanding, but I don't believe your "new version"
> > scenario makes practical sense. If an organization is implementing a
> > new version and not ready to force that change on certain
> > applications, departments, etc., wouldn't they want just that - no
> > change to those areas? They're likely not going to impose the need to
> > change a slew of existing clients to use the old VDB just to enable
> > new clients to use the previous VDB name. Rather, they'd want to
> > deploy the new VDB with a new name that only the new clients use.
> > Then migration to the new VDB name for other clients could be easily
> > scheduled and managed. Seems like the alternative would be a
> > change-control nightmare.
> >
>
> Here is how it works. All clients are using an existing VDB and
> development creates a new version of that VDB. They put it through all
> the testing and identify any possible conflicts and changes that a
> client may need to make. The VDB is then slated to be migrated to
> production during their quarterly maintenance window. However, a small
> group within the organization have not been able to complete all of
> their testing necessary to use the new version of the VDB. In this
> case, a business decision is made to proceed with the migration into
> production and the "small group" is notified that they have until MM/dd
> to complete their testing or they will need to point their clients at an
> old version of the VDB. The old version will be left in production but
> as a deprecated source.
> --
>
> Larry O'Leary
> Middleware Support Engineering Group
> Global Support Services
> Red Hat, Inc.
> loleary(a)redhat.com
> 1.866.LINUX70 (+1.314.336.2990) xt 81-62909
> Office: +1.314.336.2909
> Mobile: +1.618.420.7623
> --
> Looking to carve out IT costs?
> http://www.redhat.com/carveoutcosts/
>
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
--
Larry O'Leary <loleary(a)redhat.com>
Red Hat, Inc.
14 years
Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
by John Doyle
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
14 years, 1 month
Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
by Barry Lafond
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
14 years, 1 month
Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
by Barry Lafond
I've create a couple of use-cases we can all "attack".
Read them over and see if they make sense.
They assume Ramesh's proposed "merged" VDB concept.
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..
14 years, 1 month
Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
by Daniel Florian
Thanks that clears a lot up. I like the approach. A few more questions though:
- Don't really see how you can create the preview VDB right after creating the model. How do you know what Teiid server the connector will come from? Seems like this will have to wait until the connector is chosen/created. Unless you are assuming there is one and only one Teiid server used to preview. Also would assume then that if the user has not designated any servers then preview would be disabled.
- Don't understand why one and only one Teiid server has to be picked for preview. Why can't you preview a model on a Teiid server running say Teiid version N. And also preview the same model using a different source binding to a different Teiid server that is running version N+1. Not sure how if this is a valuable use case or if there are any valuable use cases but it doesn't make sense to me to limit them to only one.
- Doesn't seem like we currently can get workspace indexes for just one model or for a set of selected models. This will be new functionality right?
- Don't think Teiid would care about the VDB name (correct me if I'm wrong). We should come up with the names and pass in via API. And since we'll have a programmatic way of creating the names we wouldn't need to keep a mapping.
Cheers
----- 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
14 years, 1 month
Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
by Daniel Florian
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
14 years, 1 month
Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
by Daniel Florian
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
What would the API calls look like along the way? What is done in the Designer along the way? Does Designer have a local version of the VDB? Does Designer still convert our indexes to theirs (didn't know we were doing this)? Is Designer persisting any data relating to preview (source bindings for instance)?
Sorry lots of questions.
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Friday, March 26, 2010 10:27:32 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] 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
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 1 month
Re: [teiid-designer-dev] Potential Designer Source Bindings Strategy
by Barry Lafond
I like this simplified concept... realizing it adds complexity to Teiid.
>From a broader perspective, though, it could provide more opportunities for "other tooling" options for "Preview" functionality. (i.e. flexibility)
Barry
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Friday, March 26, 2010 10:27:32 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] 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
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 1 month
Re: [teiid-designer-dev] other model types
by Barry Lafond
I don't think there is any "Designer" driver for keeping ALL model types except for John's point of decorating in VDB Editor, but it appears the provider for that table uses a "File" or ModelResource to get the image. It does not use the xml modelType data. So I'd say go with the short list.
But, to play devil's advocate.... if we have a FUNCTION or TYPE model, what do we put as the ModelType in the xml? I guess not add the attribute for those models?
Barry
----- Original Message -----
From: "Steven Hawkins" <shawkins(a)redhat.com>
To: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Thursday, March 25, 2010 8:36:23 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] other model types
Just to clarify, model is an element under vdb and has a type attribute that allows for the enumerated values {PHYSICAL, VIRTUAL, FUNCTION}. Given the assumption that the new vdb.xml file replaces both the ConfigurationInfo.def and the MetaMatrix-VdbManifestModel.xmi, I am trying to ensure that the vdb.xml contains all the necessary information. So to have entries for all possible models (and there by a place holder for property elements), there needs to be an enumeration value for each model type.
On the other hand if you are saying Designer no longer has use for the information that was in MetaMatrix-VdbManifestModel.xmi, then Teiid does not need to have model entries for anything other than PHYSICAL, VIRTUAL, or FUNCTION model types.
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Thursday, March 25, 2010 5:03:22 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] other model types
On Mar 25, 2010, at 5:00 PM, Steven Hawkins wrote:
> Now we have:
>
> Barry - include them all
>
> and
>
> John - include them only if there is some ui reason
>
> So they should be included then, because Designer is a ui and used to use those values for something?
>
> Just to make sure my assumptions are correct, if there is additional values you guys want to track, then they will be set as properties on the model in the vdb.xml rather than going into a separate model manifest (such as the old entries for model, path, uuid, or update time)? And if that is the case then it seems like you will want model entries in the vdb.xml for these other model types.
Yes, the property support is a good point. Unless Barry knows of a specific reason why the types are anything more than just a UI concern, it seems like we'd just use the generic property name-value pair support in the vdb.xml to support anything specific to the UI. Why would you guys support UI-only model types in the main schema if they're not useful in the runtime?
JPAV
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
14 years, 1 month
Re: [teiid-designer-dev] other model types
by Steven Hawkins
Just to clarify, model is an element under vdb and has a type attribute that allows for the enumerated values {PHYSICAL, VIRTUAL, FUNCTION}. Given the assumption that the new vdb.xml file replaces both the ConfigurationInfo.def and the MetaMatrix-VdbManifestModel.xmi, I am trying to ensure that the vdb.xml contains all the necessary information. So to have entries for all possible models (and there by a place holder for property elements), there needs to be an enumeration value for each model type.
On the other hand if you are saying Designer no longer has use for the information that was in MetaMatrix-VdbManifestModel.xmi, then Teiid does not need to have model entries for anything other than PHYSICAL, VIRTUAL, or FUNCTION model types.
----- Original Message -----
From: "John Verhaeg" <jverhaeg(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Thursday, March 25, 2010 5:03:22 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] other model types
On Mar 25, 2010, at 5:00 PM, Steven Hawkins wrote:
> Now we have:
>
> Barry - include them all
>
> and
>
> John - include them only if there is some ui reason
>
> So they should be included then, because Designer is a ui and used to use those values for something?
>
> Just to make sure my assumptions are correct, if there is additional values you guys want to track, then they will be set as properties on the model in the vdb.xml rather than going into a separate model manifest (such as the old entries for model, path, uuid, or update time)? And if that is the case then it seems like you will want model entries in the vdb.xml for these other model types.
Yes, the property support is a good point. Unless Barry knows of a specific reason why the types are anything more than just a UI concern, it seems like we'd just use the generic property name-value pair support in the vdb.xml to support anything specific to the UI. Why would you guys support UI-only model types in the main schema if they're not useful in the runtime?
JPAV
14 years, 1 month