Perché NHibernate non elimina prima gli orfani?

Question

Sto cercando di capire perché NHibernate gestisce uno a molti cascata (usando cascade = all-delete-orphan) come fa. Ho incontrato lo stesso problema come questo ragazzo:

Forcing NHibernate to cascade delete before inserts

Per quanto posso dire NHibernate esegue sempre inserti prima, poi gli aggiornamenti, poi cancella. Ci può essere una buona ragione per questo, ma non posso per la vita di me capire quale sia questa ragione. Spero che una migliore comprensione di questo mi aiuterà a trovare una soluzione che non odio :)

Ci sono buone teorie su questo comportamento? In quale scenario la cancellazione degli orfani non funzionerebbe? Tutti gli ORM funzionano in questo modo?

Answer 1

MODIFICA: Dopo aver detto che non c'è motivo, ecco un motivo. Diciamo che avere il seguente scenario:

public class Dog { 
    public DogLeg StrongestLeg {get;set;} 
    public IList<DogLeg> Legs {get;set; 
} 

Se si dovesse eliminare prima, e permette di dire si eliminano tutti Dog.Legs, allora si può eliminare lo StrongestLeg che causerebbe una violazione di riferimento. Quindi non puoi CANCELLARE prima di AGGIORNARE.

Diciamo che aggiungi una nuova gamba e che la nuova gamba è anche la StrongestLeg. Quindi devi INSERIRE prima di AGGIORNARE in modo che la Leg abbia un ID che può essere inserito in Dog.StrongestLegId.

Quindi è necessario INSERIRE, AGGIORNARE, quindi ELIMINARE.

Anche come ibernato è basato su Hibernate, ho dato un'occhiata a Hibernate e ho trovato diverse persone che parlano dello stesso problema.

• Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)
• Non lazy loaded List updates done in wrong order, cause exception
• wrong insert/delete order when updating record-set
• Why does Hibernate perform Inserts before Deletes?
• Unidirection OneToMany causes duplicate key entry violation when removing from list

E qui è la migliore risposta da loro:

Gail Badner ha aggiunto un commento - 21/feb/08 14.30: Il problema sorge quando una nuova entità di associazione con un ID generato viene aggiunta alla raccolta. Il primo passaggio , quando si unisce un'entità contenente questa raccolta, è cascade salvare la nuova associazione entità. La cascata deve verificarsi prima delle altre modifiche alla raccolta. Poiché la chiave univoca per questa nuova entità di associazione è la stessa di un'entità che è già persistente, a ConstraintViolationException è generata. Questo è un comportamento previsto.