Hibernate version: 3.2.0.ga

MySQL 5.0.41

Hi!

Is it principally possible to manipulate the id of entities after a backup/restore-scenario for classes that are annotated with



i.e. their ids are generated automatically and not provided by the client.

We have an application that uses more than one persistence unit with object relations crossing the PU's boundaries, so we maintain these relations "by hand" based on the id.

And, which is another reason for my question, we'd like to keep the id of objects of some of the entity classes constant after a backup/restore because their are referenced from outside the application.

regards,
Andreas

I don't understand really what you mean.
Backup/restore of databases will not change the id, or maybe you want to do backup restore at the Java level, in this case look at session.replicate

Sorry, forgot these details. Yes, I want to do it at the Java level to "transfer data" between different versions of the application with possible changes in the object-relational-mapping, i.e. backup all data running under one version of the program to a version independent xml-format, then deploy the new version und restore all data from xml.

But the big problem seems to stem from the fact, that we use "hibernate through JPA", i.e. there is no Session, but an EntityManager et al.
There is no replicate then, unfortunately.

But thanks for your reply.

do (Session) entityManager.getDelegate()
You will have the underlying session

Well, just tried that.

But despite the apidoc which says...

Persist the state of the given detached instance, reusing the current identifier value. This operation cascades to associated instances if the association is mapped with cascade="replicate".

...a new one is generated. :-((((

I debugged replicate() and found that in the end it uses the prepared insert-statement that leaves out the id-column, hence a new value is generated (in our case by an autoincrement field of MySQL5). But at least in MySQL you can set the value of an autoincrement field if it is given in the insert statement.

This is somehow related to

http://forum.hibernate.org/viewtopic.php?t=948071

I want to import my xml-backup'd data in a fashion that is contrain-friendly. I.e. objects are inserted back in an order where new objects only reference objects that are already there. Plus I don't care for replication-cascading. I only want the ids of my main objects preserved as they act as keys to the outside that mustn't change after first use. Internal ids for embedded relations may change freely.

So I have to go back to the other idea to "solve" this...add another column to each relevant entity class with an external id that is initialized by the value of the auto generated id and then stays untouched on each backup/restore.

But thanks for trying to help anyway!

Much appreciated.

Well, autoincrement columns cannot be fooled I think