Hibernate version:
3.05
Bonjour a tous,
Lors de tests unitaires, j'ai fait certaines constations qui me laissent perplexe. Les questions que cela soulève sont en bas du message
1) cascade delete-orphans
imaginons le code suivant :
Code:
parent.setChildCollection(new ArrayList());
imaginons également que nous avons besoin d'exposer le setter de la collection (ne portons pas le debat la dessus).
J'ai remarqué le comportement suivant :
-
Si parent est persistant, une exception est levée au flush indiquant qu'il est interdit de dereferencer la collection initiale lorsque l'on a un delete orphans. Pourquoi pas.
-
Si parent est detaché et qu'on rattache plus tard par un update, aucune exception n'est levé, la collection est effectivement mise à jour mais les orphelins ne seront pas supprimés.
Ce qui est embétant, c'est que le comportement est différent même si apparament ce scénario n'est pas sensé être supporté
2) cascade delete-orphans (autre point).
Sans rentrer dans le détail, j'ai remarqué que les delete-orphan reattache les orphelins à la session (contrainte imposée par le delete ?). Ces objets sont référencés par le snapshot. Ceci lève donc une exception au moment du delete si l'objet détaché a effacer existe déja dans la session.
Il est malheureusement possible de tomber (certes rarement) sur ce cas, dont la bonne execution est peu prédictible (dépend de ce qui a été chargé par hibernate précédemment)
3) PersistenceContext.addInitializedDetachedCollection(PersistentCollection collection, CollectionSnapshot cs, EntityMode em)
Je ne sais pas si cette méthode est publique ou interne à hibernate. Si j'ai bien compris, cette méthode sert à rattacher une collection initialisé par une autre session. La collection est bien stockée dans le PersistenceContext en revanche la collection n'est pas rattachée à la session courante (eg PersistentCollection.setCurrentSession(...)). Dans mon cas d'utilisation, cela me conduit à une NPE au moment du flush (dans AbstractPersistentCollection de mémoire).
Suite à ces constatations, voici les questions que je me pose (dans l'ordre inverse des constatations :-) ) :
3) --> est ce normal ou est ce un bug ?
2) --> Hibernate est il reellement obligé de vérifier l'unicité (eg. PersistenceContext.checkUniqueness()) des objets que l'on va effacer dans le cas d'un cascade-delete-orphans (les elements ne sont référencés que par le snapshot de la collection)?
1) --> Je trouve dommage qu'il soit interdit de faire un setChildCollection lorsque l'on a cascade-delete mais j'imagine que cette restriction n'est pas la pour le plaisir ;-).
Pour notre projet nous avons mis en place un mecanisme qui tolère un setCollection lorsque la collection pasée en parametre implémente PersistentCollection (nous ne pouvons pas utilser merge). Ce mécanisme réattache la collection au persistentContext et à la session puis réattache les elements du snapshot a la session. Hibernate pourrait il proposer nativement ce genre de mécanisme ?
1) --> A t on le droit dans le cas ou l'on a pas de cascade-delete-orphan de faire un "setCollection" sur un objet hibernate ?
Merci de l'aide que vous pourriez m'apporter.
Christophe Brethes