It seems to me that you are expressing the concept that even the natural key of an object has to be immutable, which I think is wrong.

Removing an object from a persisted collection and adding there another with the same natural key BUT DIFFERENT PK is a legit operation. Why shouldn't it be allowed? Otherwise, what is the meaning of stressing about the need and importance of an immutable PK?

Thereby, in order to overcome UK problems, it seems evident to me that DELETEs should be performed before INSERTs. Why is the Hibernate team so reluctanct in accepting this? What is the problem?

Also note that just removing, then flushing the session, then inserting is not always a solution. Think, in example, to the case of a Long-running Conversation with the "session-per-conversation" pattern (cap. 11.1.2). In that case one should "flush()" only when the whole unit of work is completed. You can't simply do it when you like... This would mean that one has to store the add()s issued to a persisted collection somewere, in order to issue them at the end of work unit after the first flush. This seems suboptimal to me since it is part of what an Hibernate collection is supposed to do...

Again, what is the problem with respecting the delete-update-insert sequence? I'm missing it.

This issue was raised a long time ago and there still doesn't appear to be an answer to one simple question:

Why does Hibernate perform Inserts before Deletes?

Forget about all the rest of the dialog on this thread, but please give a good reason for this behavior. I'm sure there is one that just needs to be explained.

Thanks,
Smitty

I agree. Please address this issue. I need an index on my key+listIndex to prevent hibernate from messing up my data and then never recovering from the dups.

I have the same problem! I just want an unique constraint on foreign key and index column in my table. So I need that delete be performed before insert. I don't want break my database integrity because Hibernate can't do the right thing! Apology, but I think that this is a defect.

Gavin's advice regarding the synchronization of the UK and PK is the only thing that worked for me. You must define a composite key that matches your unique constraint. I had the same problem with the inserts and deletes not occurring in the correct order (I was receiving a constraint violation when I did a delete and then an insert within the same transaction). I had a synthetic PK defined for the table, and an additional UK with three separate columns involved. The inserts and deletes occurred in the correct order only after I dropped the synthetic PK column and added the necessary annotations related to integrating an @EmbeddedId that matched the UK. This link shows you what's needed to add the composite key and it's annotations:

http://www.ibm.com/developerworks/java/library/os-hibernatejpa/index.html

This link was also helpful:

http://opensource.atlassian.com/projects/hibernate/browse/HHH-2801

Just one additional comment that may be helpful. I did have to disable input for all of the UC (PK) attributes on the UI. I had to take the approach where I let the user add and delete existing rows, but not allow them to update any of the UC attributes (they can update other attributes, just not the ones that are part of the PK). The only time the user can alter the UC attributes is during an add (this includes validation on the backend for duplicated keys).

This makes sense, as when you change the value of one of the PK attributes, an update cannot be successful since the row can no longer be located against the original key.

I never really understood why Hibernate don't simply executes all actions in the same order they were enqueued.
I suppose most other JPA and JDO providers implement the write-behind mechanism respecting chronological order.

Making this kind of separated queues (inserts, updates, deletes etc.) in my opinion makes only sense
for exploiting the jdbc batching-feature with the maximum of efficiency.
(configuring hibernate.jdbc.batch_size > 0)

I've hit the same problem. It took some time to realize, what is actually happening.
Unfortunately, as cyboc mentioned, I can't use composite IDs and I also can't call session.flush() in-between collection.clear() and collection.add() as I don't have Hibernate session at that point (and getting it will break the separation of DAO and processing module).
So, alas, I have to write a code, that would actually merge newly created collection items into existing collection. Perhaps that's for the best, as there will be a bit less load on DB.
For those, who are interested, two relative topics on StackOverflow: 1 and 2.

I routinely have to merge deep object graphs originating from external systems (lacking my IDs), and it is almost guaranteed that any update will contain at least one of these transient-but-naturally-matches-a-persistent-collection-member merge landmines. I have created a piece of disgusting, hacky code to deal with this issue (below) by recursively digging through the graph to find and re-ID transient collection members that match the natural ID of an existing member. I follow this up with a merge() and update() and this seems to work OK.

This is just one of many issues that are starting to feel like punishment for having this use case. Life is great when every object you need to persist either originated from the DB or is new, but sadly I have to deal with matching detached entities by natural ID all over the place. I am surprised to see composite PKs posed as a solution since my experience trying to use them was that the Hibernate team's general attitude was that they weren't recommended and were mostly only supported for legacy systems.

I am obviously not the only one to feel stuck between these options: https://hibernate.onjira.com/browse/HHH-2896. Unified support for ID and natural ID across the entire persistence API would be an amazingly powerful tool, but unfortunately I have seen no acknowledgement that this is even an issue much less an idea of if/when it will be implemented (see the crickets chirping over here: https://forum.hibernate.org/viewtopic.php?f=1&t=1011626).

I have opted for surrogate PKs in the end. My thoughts on the painful experience:

Composite PKs are great for detached objects, but:
-Your model gets flooded with inherited composite IDs
-Trying to remedy this by mapping child FKs to a scalar UK in a composite ID parent buys you this bug (3.6): https://forum.hibernate.org/viewtopic.php?f=1&t=1011670
-You lose envers auditing support
-Based on the above 2, you can probably expect to find other holes in stated behavior of Hibernate when it comes to composite PKs
-Your DBA hates you
-Performance takes a hit from the sheer volume of repeated information

On the other hand if you use surrogate PKs when you have to deal with detached objects:
-You need to either hack something up like I did or manually pick though your entire graph to weed out the transients that match persistent collection members
-You lose session.get() and 2nd level caching by natural IDs. Only option left is query caching. Not very fun if, like me, you are receiving 10,000,000s of detached objects and needing to resolve them quickly against potential DB or session matches. I have resorted to managing my own caches of natural ID-ed objects in EHCache
-Defining natural UKs containing an FK parent ID gets awkward

alecbritton, thank you for code snippet! I would be happy if that code can help in the case with collections (first transient entities are persisted and then the collection elements are removed). If your code is applied just before passing the parent object to "saveOrUpdate()", then the transient entities will be re-associated, but collection elements will be removed anyway.

The only alternative I see now is to wrap Hibernate collections into custom collections and flush the session on collection clear().

IMHO the behaviour of reordering the SQL-statements is not acceptable and should be offered as optional optimization-configuration parameter and should be clearly described. Especially since it forces a specific way to use PKs (and many people simply prefer surrogate primary keys to natural keys or any kind of composite pks) - making the world harder for people who model top-down (starting with the ER-Model) - as this thread shows this behaviour is a real pitfall, since the expected (progammed) semantics of your code is actually changed (there is normally a reason why I do x first and then y!).

And saying "you are using hibernate the wrong way" is way too easy to do and neither nice nor helpful.

Cheers, Arndt

PS: To sum it up: A config-falg to en-/disable the reordering of sql-statements would be greatly appreciated.

If you happen to use Oracle, this issue may be solved by using deferrable index constraints as in:


Ref: http://docs.oracle.com/cd/B28359_01/server.111/b28286/clauses002.htm#CJADJGEC

Yes, thank you, I have read the post on oracle, in fact starting with Postgres 9.1 (maybe 9.0) we can do this also with Postgres, but we are still on 8.4 and anyways I think it would be good to offer a way to configure this behaviour, since it also (using prepared statements) makes debugging the actual SQL queries nearly impossible - since you do not see the values that will be set _AND_ you cannot rely on the order you issue your SQL-statements.

Thanks anyways for the hint on Oracle ;) - the DB was actually the first part I was looking into...

Cheers, Arndt

(dig, dig...)
Now it's 2017 and Hibernate still executes inserts before deletes...

It's 2017, and people still try to delete and insert entities instead of updating or merging them?