[ENH] Torque OM jar generation per backend database

• Key: JS1-542
• Type: New Feature
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: David Sean Taylor
• Reporter: David Sean Taylor
• Component/s: Database
• Affects Version/s: 1.6-dev
• Fix Version/s: 1.6-dev

Description

Creates torque specific bindings for the selected database.
Goal: end users will no longer have to recompile the source to get support for a different database than hypersonic. This requirement has been the source to a large number of problems reported on the user list.

on the distribution site, I'd like to provide several small jars for each torque-supported database:

+ 1.6-binary
  + torque
      + hypersonic
          jetspeed-torque-om-1.6.jar
      + mysql
          jetspeed-torque-om-1.6.jar
      + axion
          jetspeed-torque-om-1.6.jar
      + sybase
          jetspeed-torque-om-1.6.jar
...

prefer to have all the jars named the same to lessen the chance of someone accidently having 2 jars installed.

Comments

[David Sean Taylor]

tested on hypersonic and mysql
if anyone else could test against other database much appreciated

[David Sean Taylor]

> - With a clean setup (meaning no jetspeed-torque-om jar ever generated before you can't build or clean from > the root project because it fails with a missing dependency. I resolved this by building the jar once from > the torque-om subproject but this should be handled better I think

The Torque build is set as a pregoal to java:compile.
Wonder why that isn't enough, since it does a jar:install

> I tested this with Oracle9i and can confirm it working.

The big gotcha here is when you go to create a new user.
Thats when Torque fails miserably: since the generated code for Oracle requires sequences.
A certain percentage of database operations actually work, even know the code was generated for Hypersonic.

[Ate Douma]

> The Torque build is set as a pregoal to java:compile.
> Wonder why that isn't enough, since it does a jar:install
Because the jar is defined as dependency in the main project.xml and maven first it to be resolved before it even starts with the java:compile

>> I tested this with Oracle9i and can confirm it working.
>
> The big gotcha here is when you go to create a new user.
> Thats when Torque fails miserably: since the generated code for Oracle
> requires sequences.
Sorry, I only tested it out yet with the buildin users so I missed that one! It certainly is a killer...
Do already have an idea how to handle that?

[David Sean Taylor]

> Because the jar is defined as dependency in the main project.xml and > maven first it to be resolved before it even starts with the
> java:compile

The jar is in the remote repo, should work as is

>> I tested this with Oracle9i and can confirm it working.
>
> The big gotcha here is when you go to create a new user.
> Thats when Torque fails miserably: since the generated code for Oracle
> requires sequences.
Sorry, I only tested it out yet with the buildin users so I missed that one! It certainly is a killer...
Do already have an idea how to handle that?


Well thats the whole point.
There needs to be one jar per database.
So you change the torque-om/project.properties:

torque.database = oracle

and then rebuild

For the 1.6 release, I was planning on prebuilding each and every database (and signing), ... i know