Hello

I use my persistence manager to remove an entity object, and then I create a new object with identical properties to the one that I just removed. When I attempt to have the entity manager commit, it violates the uniqueness constraint on my database. It appears hibernate is adding the new object to the database before deleting the original. Is there anyway around this problem?

The problem goes away if I run a JPQL query searching for the original, removed object prior to creating / persisting the new object (note the query returns null).

Thanks in advance

Hello? Anyone? Bueller? Bueller? Bueller?

Why do you delete a row when you want to insert it again with the same properties?!?

You could try delete, flush, insert, commit.

I don't want to do that, but I could imagine the user doing that. I could in theory keep track of these objects myself, and then identify if the user is taking this action and handle it appropriately, but then I would just be building my own entitymanager.

Maybe flush is what I want though - I will try adding that. Thanks for the help.

you do. If you don't flush there's no guarantee the transaction will have been committed to the datastore.

I do think it a bit suspicious though that you'd get that error if both the delete and insert are in the same transaction, as it suggests the order of operations is different from the order in which the actions were added to the transaction.
That's not what I'd expect to happen.
Or are you talking separate transactions for the delete and insert with both of them open simultaneously?

Hi, thanks for followup. I'm using just one transaction, and I agree it is suspicious. Then again, is there any guarantee about the order of execution within a transaction? I just assumed that in the "magic behind the scenes" it was happening efficiently (and in a valid order!). But beyond that I made no assumptions about the order.

We actually redefined the system so that this doesn't happen at the user / business layer, but I would be interested in understanding why the order is scrambled, etc.

If you call
session.delete(entity);
session.flush();
session.save(newEntity);
the statements are executed in the correct order, because session.flush() triggers the delete-statement before the next flush() or commit() can execute the insert.

If you do
session.delete(entity);
session.save(newEntity);
session.flush();
you cannot be sure that the statement are executed in the correct order.

Thats how I understood flush().

But flush may commit any other changes, right? So in order to do a delete this way, I need to accept the fact that I'm saving any other changes made to entities persisted with that entity manager.

My workaround has been to use a spare entity manager to carry out delete operations, which I can then commit immediately.