Discussion :

[Fichman]

qui est normalement une collection héritant de PersistentCollection

euh....non, je ne sais même pas ce que c'est...
Concrètement ça se traduit par quoi ?

[Rei Ichido]

Dans ton code, par rien
Concrètement, tu utiliseras probablement la collection sous la forme d'un Set, ou d'une List. Tu peux toujours regarder l'API pour voir le détail de ce qu'il y a dedans, mais ce n'est pas du tout crucial ; la seule chose dont il faut se souvenir, c'est garder l'objet collection renvoyé par hibernate pour qu'il garde trace des ajouts (ça de toute façon il le gère bien même si tu crées une nouvelle collection) mais surtout des suppressions.

Si tu ne contrôles pas ce qui se passe côté IHM, tu peux toujours faire le différentiel à la main en rechargeant l'objet, voire gérer le cas par une procédure stockée en PL/SQL à laquelle tu enverrais la nouvelle collection.

[Fichman]

Mais même si je garde du côté serveur la collection telle qu'elle m'a été renvoyée par Hibernate, il faudra quand même que je fasse moi-même la suppression à la main dans cette collection en fonction de ce qui m'est renvoyé par l'utilisateur puis que j'affecte cette collection à mon objet père je suppose... c'est quand même pas terrible D'autant plus que j'en ai une pelletée de collections dont certaines se trouvent elles-mêmes dans des collections !


Pareil, le fameux delete-orphan... ben il marche pas non plus même si la clé du parent est nulle... Je suis maudit, où alors j'ai rien compris

[henpower]

est ce qu'on peut également voir le code de suppression ?

[Rei Ichido]

Mais même si je garde du côté serveur la collection telle qu'elle m'a été renvoyée par Hibernate, il faudra quand même que je fasse moi-même la suppression à la main dans cette collection en fonction de ce qui m'est renvoyé par l'utilisateur puis que j'affecte cette collection à mon objet père je suppose... c'est quand même pas terrible D'autant plus que j'en ai une pelletée de collections dont certaines se trouvent elles-mêmes dans des collections !

Non non, simplement dans ton objet, mettons qu'il y a un set, disons mySet : dans ton objet tu laisses le getter/setter sur mySet, mais tu ne te sers jamais du setter (tu laisses Hibernate le faire).
Ensuite quand on utilisateur veut supprimer un objet, tu implémentes deleteFromMySet, et c'est cette fonction que tu appelles chaque fois qu'il veut faire un delete. Idem, une fonction pour le addToMySet (qui gère le cas du set null, là bien sur faut en créer un, sans souci puisqu'il n'y aura pas eu de suppression).
Maintenant, si dans ton IHM tu récupères forcément un nouveau Set, tu peux faire une fonction qui fait dans l'ordre mySet.clear() puis mySet.addAll(myIHMSet).

Voiloute

[Fichman]

Ah ok.

Le problème est que dans mon cas, le setter sur ma collection est obligatoirement utilisé parce que mon interface graphique est en Flex donc mes objets sont settés à chaque renvoi du côté serveur (d'où certainement une partie de mes problèmes). Peut-être qu'Hibernate considère que ce sont des collections différentes donc il ne supprime rien.

Donc au final je pense que je suis bloqué, et ben tant pis je vais faire ça à la main.

[Rei Ichido]

Tu peux ruser : tu te construit une collection intermédiaire destinée à l'IHM, et ensuite pour alimenter la collection de ton objet, tu fais ce que j'écrivais plus haut :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
public void fromIHMToDomainMySet() {
    this.mySet.clear();
    this.mySet.addAll(this.myIHMSet);
}

(Note : je te laisse le soin de gérer les cas de nullité )

[Fichman]

Je vais effectivement devoir faire une "synchronisation" à la main entre l'ancien objet remonté d'Hibernate et le nouveau récupéré de l'IHM.
J'ai testé une suppression d'élément(s) côté serveur, sans passer par l'IHM, ça entraine bien une suppression en base. ça confirme bien que Hibernate perd tout lien avec l'objet une fois passé à l'IHM (ceci étant dû à la technologie utilisée, Flex, car il me semble pas avoir eu ce problème avec Struts).

Je me suis aussi rendu compte, qu'une requête HQL ne prenait pas en compte tous les aspects du mapping comme la suppression des objets many-to-one(unique à true) ayant un cascade="all" lors de la suppression du "père"...
Je ne sais pas si c'est un bug ou si c'est normal.

[Fichman]

Bon synchronisation effectuée... c'est très chiant mais ça marche.

Je vais aller me renseigner sur le forum Flex pour voir s'il y en a qui ont une meilleure méthode parce que là c'est moche (je trouve)