i am still learning the odds and ends of ORM. I just ran into a problem where i delete some data then re-insert similar data. THe data has a name column which has a unique constraint on it and i am essentially deleting the old data and re-inserting the new data with the same name.

This causes a problem because the inserts are flushed to the db, i think because I am using identity id generation but the deletes are not flushed until the end of the transaction. So the inserts throw a unique constraint violation (on name field) because the delete was not executed first.

I would have assumed that hibernate would automatically flush prior sql calls if it needs to flush the insert call, but i guess it saves the deletes until the very end. So this leaves me in a conundrum. Should I be flushing after every delete in my application? Is there a setting which will automatically do this?

Or am i misinterpreting this situation?

thx

You can configure when Hibernate does flush. It is explained in the Hibernate reference.
10.10. Flushing the Session

normally you have to flush in seldom cases.
Eg. if you want to get the value from an auto-increment field.

when you use ids generated by the database, your database should not create double entries. You may have another problem here.

Regards Sebastian

I don't believe I have an additional problem. I am not inserting an additional value with the same id just the same name, and there is a unique constraint on the name. But I delete the old one first. Because hibernate is required to flush the identity inserts when they are called in order to obtain an id it does this immediately however it does not flush the deletes until the end of the transaction per it's performance strategy.

In my mind this doesn't make sense, if it knows it has to complete the sql inserts why not flush everything up until that point. However since it does not my question is what is the best strategy to handle this? Should I just flush after every delete?