Hello,
________
The case:

We want to switch from a JDBC oriented to a Hibernate-oriented application. We have a exisiting database. But we have the possibility to change the database scheme. One importend task is the migration of the data from the old to the new scheme.

The persistend objects in the new scheme have the uuid.hex as primary key. In the old scheme the primary key are mostly bussiness attributes (sometimes with a sequence number).

_________
The idea:
So, we think the best way to migrate the data is to write some java-code with jdbc to load the old data, build the new objects in the memory and write it with the new mechanism in the new scheme in one big step. After that the old tables will be deleted in the database. One disadvantage is we can not use our database experts to write the load jobs with sql (because of the uuid.hex).

We don't want to build a O/R-Mapping to the old scheme because we think this will be to complex.

_________
The question:
Does anybody has experience with such a case (e.g. drawbacks) and give us some hinds or is there a better way to do it.

Thanks and Regards
Oliver Nautsch

if you already have business key : you're lucky.
Keep it as unicity constraints and implement your equals and hashcode method using these "business" keys.
Now for the id, map it in new generated primary key (not assigned), using for example sequence.
Get all jdbc calls, take it out in a DAO layer, then rewrite all this code using hibernate APIs.
Don't forget threadlocal pattern.
If you want to tune data access (select), turn on sql log, send it to your DBA and if there is a great tunning to do, use your DBA advices into a SQLQuery (hibernate API).
That's a good start.

Thanks for you hints! We want to do it exactly this way (DAO-Layer, equals, hashcode, unicity constraints). But what do you think about the migration of the data? We have to fill up the new primary key for each record and what do you mean with "... (not assigned) ..."?

Thanks and Regards
Oliver Nautsch
PS.: After finishing this job I will give feedback...

Well, load your old data with JDBC, copy it over to a hibernate mapping object, then save it - should be doable.

I use this way to add generated primary key:

1. add nullable field to table.
2. execute update statement
"UPDATE MY_TABLE SET PK = nextval('mySec')" from UI or command line client.
3. Alter table to make this field not null and add primary key constraint.
(It is not the rocket science, you will find how to write commands in doc)

This schema change doe's not break legacy code (if SQL is static), it helps to port code too, you will get working application on new chema woth old data and it must help to detect problems if you will break something with migration.

I think we will go a mix between the JDBC->HibernateObject->DAO(session.save) and the suggestion from baliukas (I like the idea.)

So, I will come back with our experiences in a while.

Thanks for help and Regards
Oliver Nautsch

If you can avoid the uuid.hex approach, you could of course always just use an id which is autogenerated by the db ...