Hi,
My current project (which I hv joined midway), uses raw JDBC code for persistance.
The task in hand is -
Make it compliant with Oracle, MS SQL Server and DB2.

The estimates drawn up include "80 hrs per database vendor" -- time allocated to schema migration/ trigger rewriting etc..
per database.

As I have used Hibernate in the past I know with hibernate, changing the database vendor means changing only the hibernate.properties. (dialect, connection string, etc.

but Can Hibernate help in reducing the "80 hrs per database vendor" estimate?
(I went thru the Roundtrip engineering section of Hibernate but it was not clear to me how that will help in schema migration/ trigger rewriting issues per database)

Hibernate version I plan to introduce : 2.1.4

Name and version of the database that need to be supported : Oracle, MSSQlServer, MySql, PostgresSQL, DB2

IMHO this depends on your application. If you have some means of abstraction between the business logic and the JDBC code, maybe a kind of DAO pattern, then I think it may be a good idea to migrate once to Hibernate.

On the other hand, if the JDBC Code is part of the business logic, you would habe to rewrite this one as well, wich is likely to be more expensive.

HTH
Ernst

Thx,

Yes the current logic uses business layer talking with JDBC code thru a DAO pattern.

The one time coding I percieve will be coding the hydrated pojo's (replacing the JDBC and SQL classes) -- but the issue my peers want resolved first is --

Can Hibernate help in cutting down the time required - in DB vendor change - to be specific - The time required for migrating objects inside of the database - such as triggers, constraints etc.

Currently this activity is estimated at 80 hrs per db vendor.

I think the task Schema2DDL cud do it partially (at least upto the DDL level) - but then what about Triigers/ constraints/ stored procedures?

No, Hibernate is one layer above, you will have to port triggers, constraints and procedures. Some of the procedures might have a place in your Java application though. They would then be portable, Hibernate is the right tool to implement the persistence aspect of this logic in Java.

I wouldn't consider porting complex SPs on DB2/Oracle/MSFT SQL... It's difficult to imagine anything more painful. However, if your Java application is not the only application that accesses the data, you might have to keep not only the constraints (keep them in any case), but also the triggers/SPs.

P.S. There is not much more to say, your question is very generic.

Of course, once you have the hibernate mapping files, you can quickly generate the db schema itself for the different databases using SchemaExport, if that was your question. I think I've read you can also put (probably only simple?) check constraints in the mapping files, so those would be generated as well. That doesn't help you with the SPs, though.