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.
14 years
Wiki spaces
by John Doyle
What do you guys think about creating some sub-spaces in the Teiid wiki for documents. Given that there is such a change between the 6.X documents and the 7.x, it seems to me a good way of clearly separating things. I'm concerned that users will be confused otherwise.
~jd
14 years
next 7.0 milestone
by Steven Hawkins
Hello all,
I think that we're looking stable enough and making good progress on the docs to have the next milestone on Monday. If you have extra time please ensure any functionality your responsible for isn't critically broken using the latest build.
The Teiid Team
14 years
Re: [teiid-dev] Teiid dialect in Hibernate
by Ramesh Reddy
I guess your last statement is the real problem we have in running these
tests against Teiid.
Shelly, do you know if you can generate the DDL per test to avoid the
issue? Or are you saying in a given Hibernate test uses same table with
multiple different columns?
Ramesh..
On Wed, 2010-03-24 at 13:46 -0400, Shelly McGowan wrote:
> John,
>
> I did some testing with the Hibernate Test Suite using Hibernate Branch_3_2_4_SP1_CP. This
> was just to determine what issues would be exposed with the Dialect.
>
> The test reports running with the MetaMatrix Dialect and the Oracle Dialect can
> be seen here:
>
> http://dev39.qa.atl.jboss.com/~smcgowan/hibernate-reports/MetaMatrix/test...
> http://dev39.qa.atl.jboss.com/~smcgowan/hibernate-reports/Oracle/test-rep...
>
> I also generated DDL using the MM dialect:
>
> http://dev39.qa.atl.jboss.com/~smcgowan/hibernate-reports/DDL/DDL-MetaMat...
>
>
> After generating the DDL, we populated the databases with the tables. We did
> find, however, that tests reuse the same Table name with a different table structure.
>
> Shelly
>
>
> ----- Original Message -----
> From: "John Doyle" <jdoyle(a)redhat.com>
> To: "Ramesh Reddy" <rareddy(a)redhat.com>, "Shelly McGowan" <smcgowan(a)redhat.com>
> Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Wednesday, March 24, 2010 10:17:05 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [teiid-dev] Teiid dialect in Hibernate
>
> Hey Shelly,
>
> You did some work a year or so ago in order to get some AS/Hibernate tests working with the Teiid dialect. Do you have any insight or suggestions on this issue? How did you workaround the DDL problem?
>
> ~jd
>
> ----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
>
> > I had IRC conversation with Steve Ebersole about adding the Teiid
> > Dialect to the Hibernate Core in the next upcoming 3.5 release.
> >
> > He is not willing to accept any dialects that are not testable from
> > their testing framework. He said Hibernate uses a schema export tool
> > that issues some DDL queries through JDBC interface for their testing
> > to
> > work.
> >
> > Since Teiid driver does not support the DDL currently, issuing the
> > DDL
> > is not possible. He suggested that we look into ways to
> > 1) delegate the DDL calls either through the TeiidDriver
> > (https://jira.jboss.org/jira/browse/TEIID-669)
> > or
> > 2) devise a way in their schema export tool to delegate the DDL
> > class.
> >
> > also, since they already have two CR releases, chances of getting
> > into
> > 3.5 release seems slim. However, if we can make it that would be
> > great.
> >
> > Any suggestions? volunteers?
> >
> > Thanks.
> >
> > Ramesh..
> >
> > On Tue, 2010-03-23 at 13:05 -0500, Ramesh Reddy wrote:
> > > I am not dis-agreeing. Just wanted to what our options were.
> > >
> > > I do think it is valuable for Teiid be included along with
> > Hibernate.
> > > They are about to release 3.5 very soon, we need to see if we can
> > make
> > > it into 3.5 final release.
> > >
> > > So, instead of making this JIRA in the Tools, we need to make this
> > into
> > > Hibernate by communicating with its lead.
> > >
> > >
> > > Thanks
> > >
> > > Ramesh..
> > >
> > > On Tue, 2010-03-23 at 11:01 -0400, John Doyle wrote:
> > > > Ramesh-The drivers are supplied by the DataTools
> > ConnectionProfiles
> > > > and Drivers that you have to define before you use Hibernate, so
> > > > drivers are a different issue, and not something that the
> > hibernate
> > > > plug-ins have 'built in'. It's an configuration step that's
> > already
> > > > extensible in a way that Dialects don't appear to be.
> > > >
> > > > I'm personally in favor of including our dialect in Hibernate
> > because
> > > > then Tools will just work, there won't be some additional step
> > for
> > > > Teiid. It seems to me that if Oracle just works out of the box
> > in
> > > > Tools, then a fellow JBoss project should just work. The only
> > > > downside I can see to including our dialect in Hibernate is that
> > our
> > > > release cycles don't match up and changes/maintenance would have
> > to be
> > > > managed across our differing cycles.
> > >
> > > _______________________________________________
> > > teiid-dev mailing list
> > > teiid-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/teiid-dev
> >
> > _______________________________________________
> > teiid-dev mailing list
> > teiid-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years
Re: [teiid-dev] Teiid dialect in Hibernate
by John Doyle
Hey Shelly,
You did some work a year or so ago in order to get some AS/Hibernate tests working with the Teiid dialect. Do you have any insight or suggestions on this issue? How did you workaround the DDL problem?
~jd
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> I had IRC conversation with Steve Ebersole about adding the Teiid
> Dialect to the Hibernate Core in the next upcoming 3.5 release.
>
> He is not willing to accept any dialects that are not testable from
> their testing framework. He said Hibernate uses a schema export tool
> that issues some DDL queries through JDBC interface for their testing
> to
> work.
>
> Since Teiid driver does not support the DDL currently, issuing the
> DDL
> is not possible. He suggested that we look into ways to
> 1) delegate the DDL calls either through the TeiidDriver
> (https://jira.jboss.org/jira/browse/TEIID-669)
> or
> 2) devise a way in their schema export tool to delegate the DDL
> class.
>
> also, since they already have two CR releases, chances of getting
> into
> 3.5 release seems slim. However, if we can make it that would be
> great.
>
> Any suggestions? volunteers?
>
> Thanks.
>
> Ramesh..
>
> On Tue, 2010-03-23 at 13:05 -0500, Ramesh Reddy wrote:
> > I am not dis-agreeing. Just wanted to what our options were.
> >
> > I do think it is valuable for Teiid be included along with
> Hibernate.
> > They are about to release 3.5 very soon, we need to see if we can
> make
> > it into 3.5 final release.
> >
> > So, instead of making this JIRA in the Tools, we need to make this
> into
> > Hibernate by communicating with its lead.
> >
> >
> > Thanks
> >
> > Ramesh..
> >
> > On Tue, 2010-03-23 at 11:01 -0400, John Doyle wrote:
> > > Ramesh-The drivers are supplied by the DataTools
> ConnectionProfiles
> > > and Drivers that you have to define before you use Hibernate, so
> > > drivers are a different issue, and not something that the
> hibernate
> > > plug-ins have 'built in'. It's an configuration step that's
> already
> > > extensible in a way that Dialects don't appear to be.
> > >
> > > I'm personally in favor of including our dialect in Hibernate
> because
> > > then Tools will just work, there won't be some additional step
> for
> > > Teiid. It seems to me that if Oracle just works out of the box
> in
> > > Tools, then a fellow JBoss project should just work. The only
> > > downside I can see to including our dialect in Hibernate is that
> our
> > > release cycles don't match up and changes/maintenance would have
> to be
> > > managed across our differing cycles.
> >
> > _______________________________________________
> > teiid-dev mailing list
> > teiid-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years, 1 month
Teiid Tools - Designer, CDK, etc.
by John Verhaeg
The Designer team has been disconnected from the whole Eclipse CDK plug-in effort until fairly recently (our own fault due to poor communication issues). Now that I'm aware of the effort, I think we need to make some changes. At a minimum, the CDK efforts needs to be pulled into the radar of the other Eclipse tooling efforts (JBT and possible JBDS). Since this is an Eclipse tool, it "belongs with" all of our other Eclipse tools in JBT regarding building, testing, packaging, and delivery. Even from a community standpoint, having this project hosted via SourceForge somewhat hides it from that community, not to mention the JBT developers concerned with delivering a suite of tools that need to adhere to a number of guidelines to achieve a necessary level of quality and consistency. Then there's also the consideration of what level of integration we may want with other tools without our suite. Finally, we've also envisioned other possible tools for Teiid that would not fall under the umbrella of either Designer or CDK.
Therefore, I propose that we change several of our Designer components to be more generically "Teiid Tools" components. We'd want the following:
A new URL at www.jboss.org/teiidtools.html
Either a new JIRA project (something like TEIIDCDK) or changing the existing TEIIDDES project to something like TEIIDTOOLS
As with the JIRA change just described, a similar change to the mailing lists
A new home for the CDK code, either in its own project that gets pulled into the JBT build/testing/packaging framework, or within the JBT SVN.
A new Teiid Tools project page that incorporates documentation, downloads, etc., for Designer, CDK, and whatever other Teiid-related tools we invent.
Sanjay to be made a committer on the appropriate SVN.
A discussion with the JBT team concerning the CDK, when to include it in a JBT/JBDS release, etc.
Thoughts?
Thanks,
JPAV
14 years, 1 month
Teiid dialect in Hibernate
by John Doyle
Last week I attempted to reverse engineer a 6.2 Teiid VDB with Hibernate in JBoss Tools. In the latest release Hibernate tools added Teiid as an option in the Hibernate Tools UI. However, the Teiid dialect is not included in any release of Hibernate, so the Tooling doesn't work. I'm still looking for a better way, but as of now the only way I have found to get the dialect discovered in Tools is to put it in the global classpath.
I'm of the opinion that the Teiid dialect should be 'built into' Hibernate by default in order to ease the path for our existing users to use other JBoss technologies, as well as easing adoption of Teiid by existing Hibernate users. Does anyone have an opinion pro or con about trying to get the Teiid dialect into Hibernate?
~john
14 years, 1 month
Re: [teiid-dev] Hibernate reverse engineering
by John Doyle
Mike,
I got this to work in JBoss Tools, I'm sure there it can be done in the ant tasks as well. I need to follow up with Max to see if there is a more correct way to do this, but if you add the teiid dialect that is delivered in the client directory of Teiid to the global eclipse classpath, reveng works.
In JBoss Tools navigate to Window->Preferences->Java->Installed JRE's. Select the current JRE and click the Edit button. Click Add External Jar and navigate to the teiid-hibernate-dialect jar.
~jd
----- "Ted Jones" <tejones(a)redhat.com> wrote:
> FWIW, I was able to reverse engineer using JBossTools 2.0.1 and Teiid
> 6.2. This was before the Teiid dialect was added to JBossTools. I
> documented the process here:
> http://community.jboss.org/wiki/RESTEasywithTeiid. The workaround I
> had to use do to the absence of the Teiid Hibernate dialect should
> work for the latest JBossTools as well. My example involved creating a
> SEAM web app, but that shouldn't be a requirement to get the Hibernate
> objects created
>
> Ted
>
> ----- Original Message -----
> From: "Amentra" <michael.walker(a)amentra.com>
> To: "Ramesh Reddy" <rareddy(a)redhat.com>
> Cc: teiid-dev(a)lists.jboss.org, "Jason Stokes"
> <jason.stokes(a)amentra.com>
> Sent: Thursday, March 18, 2010 9:08:37 PM GMT -06:00 US/Canada
> Central
> Subject: Re: [teiid-dev] Hibernate reverse engineering
>
> It is typically run as an ant task, and behavior is tweaked via a
> config file.
>
>
>
> On Mar 18, 2010, at 3:15 PM, Ramesh Reddy <rareddy(a)redhat.com> wrote:
>
> > Does Hibernate support command line reverse engineering?
> >
> > On Thu, 2010-03-18 at 16:26 -0500, Michael Walker wrote:
> >> Thanks John. Let me know the JIRA and I'll follow it. I agree that
> >> this seems like something we should be capable of currently.
> >>
> >>
> >>
> >>
> ______________________________________________________________________
>
>
> >> From: John Doyle [jdoyle(a)redhat.com]
> >> Sent: Thursday, March 18, 2010 5:16 PM
> >> To: Michael Walker
> >> Cc: Jason Stokes; teiid-dev(a)lists.jboss.org
> >> Subject: Re: [teiid-dev] Hibernate reverse engineering
> >>
> >>
> >>
> >> Hey Mike,
> >>
> >> I just tried to reverse engineer a 6.2 teiid vdb, because I
> thought
> >> your central thrust here was incorrect and that we had everything
> we
> >> needed already, and it fails. The tooling can't find our dialect.
> >> It's in all the lists, but the classes are not getting found.
> >>
> >> I believe this to be a defect, and that with the latest release of
> >> JBossTools you should be able to reverse engineer a Teiid VDB.
> I'll
> >> see about tracking down the issue and logging a Jira.
> >>
> >> ~john
> >> ----- "Michael Walker" <michael.walker(a)amentra.com> wrote:
> >>>
> >>> To set the context: Hibernate's reverse engineering feature uses
> >> standard JDBC database metadata to automatically generate all the
> >> necessary Hibernate config files for working with the target
> database
> >> in an O/R fashion
> >>
> (https://www.hibernate.org/hib_docs/tools/reference/en/html/reverseenginee...
>
> >> ).
> >>>
> >>> The getting started guide tells me that Teiid does not currently
> >> support reverse engineering via Hibernate. This is somewhat
> >> surprising, since Teiid generally supports all the typical JDBC
> >> database metadata, making it easy to connect third-party client
> >> tools,
> >> etc.
> >>>
> >>> Does anyone on the Teiid development team know what it would take
> to
> >> extend support for reverse engineering? How far off are we here?
> >>>
> >>> Apparently, Hibernate does provide a few options for working with
> >> non-standard sources:
> >>>
> >>> 1. Create a custom hibernate.reveng.xml configuration file - This
> >> will take care of small issues such as type mismatches, or
> exclusion
> >> of certain tables
> >>> 2. Extend Hibernate's JDBCMetaDataDialect class with your own
> >> implementation
> >>>
> >>> I wonder if either option would allow us to get reverse
> engineering
> >> working with Teiid without having to make significant change to
> Teiid
> >> source. Thoughts?
> >>>
> >>>
> >>>
> >>>
> >>
> >>> _______________________________________________ teiid-dev mailing
> >> list teiid-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/teiid-dev
> >> _______________________________________________
> >> teiid-dev mailing list
> >> teiid-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/teiid-dev
> >
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years, 1 month
Re: [teiid-dev] CDK Quick Question - Config Editor
by Ramesh Reddy
On Mon, 2010-03-22 at 23:10 -0500, Sanjay Chaudhuri wrote:
>
> Had few quick questions for you. Please refer to the attached
> screen-shot:
> 1. Let me know if you are okay with the look & feel or want to it
> change it.
Looks good.
> 2. Would you prefer a Edit Button as shown and have a popup dialog
> with the all values editable for the selected row, or would you prefer
> inline. The issue with inline is the long text on the description. The
> other alternative is to have everything inline except Description and
> to only have a button next to the Description cell to have a dialog
> for editing.
> 3. How do I currently display multi-line descriptions ? \n' is getting
> converted to boxes as you can see in the snapshot.
>
IMO, inline is fine. If can further refine as we get more feed back.
Also for this version, single line description is fine to minimize
changes.
FYI, it took longer than expected but we are close to doing a milestone
with the JCA changes. If you pull in the trunk version of the Teiid you
can build all the dependencies for this project on your system. (only
after 7.0 release they will be in jboss maven repo).
Thanks.
Ramesh..
14 years, 1 month
removal of teiid-client-jdbc
by Steven Hawkins
Hello all,
To simplify our modules we will collapse teiid-client-jdbc into teiid-client. Client is already required in the client jar, contains the adminapi related classes and is isolated from other modules by having a separate common-core. You'll see this change the next time you update your workspaces.
Steve
14 years, 1 month