Re: [teiid-dev] [teiid-designer-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.
15 years, 11 months
UDF Related Changes in 7.0 Teiid
by Ramesh Reddy
In Teiid user defined functions (UDF) are defined in a special
"FunctionDefinitions.xmi" file and this file deployed in the Teiid
runtime. Some times there is jar file associated with to provide
implementation classes, and if all the functions are "push down" then it
may not require it.
Lack of name space based functions like per VDB functions, or per
Connector kind of functions were long standing requests from users
(TEIID-231, TEIID-502).
Now in the container environment with its free standing nature this file
causes trouble in terms of deploying a UDF. In 7.0, we going to bundle
this "FunctionDefinitions.xmi" file inside the VDB artifact, such that
each VDB can have its own UDF functions and at the same time solve the
deployment issues.
The tooling in the Designer 7.0 will be modified to include
"FunctionDefinitions.xmi" file in the VDB and Teiid runtime will be
modified to look for the "FunctionDefinitions.xmi" file inside VDB and
deploy it accordingly.
Thanks
Ramesh..
16 years, 1 month
Proposed Schema for "ConfigurationInfo.def" file
by Ramesh Reddy
Based on the JCA changes to the VDB artifact and its configuration the
current "ConfigurationInfo.def" file needs to be modified.
I have attached the XML schema and a sample XML file showing the new
format of this file. This format closely resembles the old format with
few additions to lot of removal of other elements.
This same XML file will serve as
1) Configuration for the VDB
2) Configuration to define a "Dynamic VDB"
3) Will serve as the persisted format in the container, when a user
modifies the associated connector bindings to a model using any
administrative tools.
Please take look at this and let me know if there are any suggestions to
improve upon.
Thank you.
Ramesh..
16 years, 1 month
Removing the object connector
by Steven Hawkins
Hello all,
Are there any objections to removing the sandbox object connector? It is now quite out of date and just imposes more maintenance work on us as we make api changes.
Steve
16 years, 1 month
Custom connectors
by Steven Hawkins
Hello all,
With the JCA work, the current rar packaging for connectors presents a few issues with the old way we used to manage dependencies. For example if I want a custom JDBC connection which introduces a new connector binding property and custom code, then I would need to create a copy of the jdbc rar, add my custom jar, and modify the ra.xml file. Since the jdbc rar contains our jdbc connector jar, now there are two copies of that jar. Management of patching becomes an issue.
Even in a simpler case which is providing my own implementation of capabilities of the Translator class would require either that I place my custom code in a higher level class loader or create a copied rar and add my custom jar. In the former case there is the possibility of class loading issues, in the latter there's the same duplicated dependency issue.
It doesn't seem that there is a simple answer to this problem. Options include:
1. Elevating all of the built-in connector jars to the same class loader as the connector api. Now there is a single place to manage/patch the dependency. This path assumes that the xml connectors will be refactored to contain only minimal external dependencies, otherwise they would still need to be managed as rar.
2. Investigate OSGI support (http://jbossosgi.blogspot.com/2009/06/jboss-osgi-runtime-as-integration.html) so that we can use declared dependencies. However this is a poor fit with the JCA model and adds additional complexities.
3. Treat all custom connector work, even extensions of our connectors, equally. Each new type requires a rar and any dependency maintenance becomes the responsibility of the customer.
Any thoughs?
16 years, 1 month
proposed 7.0 connector api language changes
by Steven Hawkins
Hello all,
With the JCA work we are in a position to make several cleanups to the connector api. First the metadata interfaces (Element, Group, etc.) are no longer necessary - as all of our metadata will be supplied via VDBs. Previously preview mode execution still supplied metadata via the QueryMetadataInterface, which then required the wrapper metadata objects. The proposed change here is to just allow for direct use of the metadata record objects. These objects are already part of the api, since they are needed for dynamic vdb work. This would address TEIID-851.
Second, and more far reaching, I would like to get rid of the I(Something) interfaces fronting the connector language impl objects. The are several reasons for this:
-inconsistent I prefix usage
-it no longer forces the protection of the impl objects, since they have been moved into the connector api as well (this change simplifies the dependencies between a connector and the engine).
-it's an oppurtunity to use more standard names for the sql constructs.
-moves another step closer to consolidating the engine and connector language implementations.
To that last point here is a proposal for name changes:
IAggregate - AggregateFunction
IBaseInCriteria - BaseInCondition
IBatchedUpdates - BatchedUpdates
ICommand - Command (Statement may be a better alternative)
ICompareCriteria - Comparison
ICompoundCriteria - AndOr
ICriteria - Condition
IDelete - Delete
IElement - ColumnReference
IExistsCriteria - Exists
IExpression - Expression
IFrom - From
IFromItem - TableReference
IFunction - Function
IGroup - NamedTable
IGroupBy - GroupBy
IInCriteria - In
IInlineView - DerivedTable
IInsert - Insert
IInsertExpressionValueSource - ExpressionValueSource
IInsertValueSource - InsertValueSource
IIsNullCriteria - IsNull
IJoin - Join (JoinedTable may also be good, since it is consistent with the other TableReference classes)
ILanguageObject - LanguageObject
ILikeCriteria - Like
ILimit - Limit
ILiteral - Literal
ILogicalCriteria - removed, can already be inferred if a condition is not a Predicate
IMetadataReference - MetadataReference
INotCriteria - Not
IOrderBy - OrderBy
IOrderByItem - SortSpecification
IParameter - Argument
IPredicateCriteria - Predicate
IProcedure - Call *I would also like to update the parser and string form of exec to use the call keyword, since it is standard
IQuery - QuerySpecification
IQueryCommand - QueryExpression
IScalarSubquery - ScalarSubquery
ISearchedCaseExpression - SearchedCase
ISelect - Select
ISelectSymbol - DerivedColumn
ISetClause - SetClause
ISetClauseList - SetClauseList
ISetQuery - SetQuery
ISubqueryCompareCriteria - SubqueryComparison
ISubqueryContainer - SubqueryContainer
ISubqueryInCriteria - SubqueryIn
IUpdate - Update
Any thoughs?
Steve
16 years, 1 month
Re: [teiid-dev] [teiid-designer-dev] VDB Versioning Feature
by Steven Hawkins
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.
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.
----- 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
16 years, 1 month
New changes for the eclipse cdk plugin
by Sanjay Chaudhuri
I have uploaded fresh changes on the cdk plugin. The plugin would now take a
repository (typically a maven repository) and be able to download dependent
jars and add to classpath automatically while creating the template. The
names of the jars and the location currently needs to be specified, as
currently there does not exist any maven repository for teiid on
http://repository.jboss.com/maven2
The downloaded plugins are put in *lib* directory of the generated project.
The generated template also uses the old way of using cdk-dist plugins for
adding dependencies. This feature will be removed in future once we have the
maven repository.
Thanks
Sanjay
16 years, 1 month
Re: [teiid-dev] XML Connectors and Supported Styles
by John Doyle
I have mixed feeling on this one. In principle I agree with Steve that as an integration engine we need to make efforts to support legacy technologies. We also have to draw the line somewhere.
I'm satisfied by the proposed solution. As you say we need ESB connectivity anyway, and the ESB is a much richer env for dealing with XML.
That said, this will certainly get us some flack. There are a lot of bad non-WSI services out there.
~jd
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> XML-Relational SOAP Connector (after the move to the CXF) it only
> supports executing "Document-Literal" style web services.
>
> XML-Source SOAP Connector is using Axis as the client library
> supports
> the "JAX-RPC" and as well as "Document-Literal" style web services.
>
> As I am working to combine these both connectors into one JBoss WS
> (native) and using only JAX-WS. Looks like JAX-WS only supports the
> "doc-literal" style.
>
> A question raised by SteveH is that since Teiid is an integration
> engine
> it should support connections to legacy technologies such as JAX-RPC
> to
> meet the user needs.
>
> One option here is move the XML Connectors to the JAX-WS style, then
> provide another connector that can be to JBoss ESB, where user can
> choose to implement any kind of transport. Teiid team would like to
> put
> this on the road map irrespective of this particular need, however
> the
> question is if this will satisfy the needs of our users?
>
>
> Thanks.
>
> Ramesh..
>
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
16 years, 1 month
XML Connectors and Supported Styles
by Ramesh Reddy
XML-Relational SOAP Connector (after the move to the CXF) it only
supports executing "Document-Literal" style web services.
XML-Source SOAP Connector is using Axis as the client library supports
the "JAX-RPC" and as well as "Document-Literal" style web services.
As I am working to combine these both connectors into one JBoss WS
(native) and using only JAX-WS. Looks like JAX-WS only supports the
"doc-literal" style.
A question raised by SteveH is that since Teiid is an integration engine
it should support connections to legacy technologies such as JAX-RPC to
meet the user needs.
One option here is move the XML Connectors to the JAX-WS style, then
provide another connector that can be to JBoss ESB, where user can
choose to implement any kind of transport. Teiid team would like to put
this on the road map irrespective of this particular need, however the
question is if this will satisfy the needs of our users?
Thanks.
Ramesh..
16 years, 1 month
