I was just wondering, is it usual for NHibernate to perform INSERTs before UPDATEs when flushing a session where items have been both removed and added from a collection of children on a parent object?

I have mapped the collection as both a bag and a set with the same result. The INSERT operations are causing a duplicate key violation on a unique index because the INSERTs occur before the DELETEs.

NHibernate does not guarantee when it will call flush (except for entities that have natively generated keys where it calls insert as soon as you call save) but it guarantees the following order when it calls flush:

1. all entity insertions in the same order as the Save was called on them
2. all entity updates
3. all collection deletions
4. all collection element deletions, updates and insertions
5. all collection insertions
6. all entity deletions in the same order as the delete was called.

So does that mean in order to have the deletions occur before the insertions I need to have the association managed at the collection end (i.e. with inverse="true" on the "one" side of the one-to-many association)?

Sorry... what I meant to say was, do I need to make the association unidirecitonal instead of bidirectional so that the association is managed by the collection rather than by the child entity?

I found a relevant Hibernate thread discussing this issue:

http://forum.hibernate.org/viewtopic.php?p=2231436&sid=968c59b7e0b0078e76094ee25f5c73c1

From this discussion, it appears Hibernate will always perform inserts before deletions on collections.

In answer to my own problem, I suspect the solution here is to use a composite-id on the child entity over the fields forming the unique index. NHibernate would not then consider the items removed and then re-added as separate items, but as the same item thus resulting in an UPDATE instead of an INSERT followed by a DELETE.