-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: delete-orphans et "setCollection"
PostPosted: Wed Dec 21, 2005 9:50 am 
Newbie

Joined: Wed Dec 21, 2005 5:26 am
Posts: 1
Location: Paris
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.