Bonjour,

Avez-vous déjà été confronté au problème de devoir modifier la classe d'un objet déja persisté (vers une sous-classe) ?

J'ai, par exemple, dans mon mapping Hib3 une classe 'personne' de laquelle dérive une classe 'responsable' contenant des attributs supplémentaires.

J'ai d'autre part dans ma base plusieurs objets de type 'personne' (ayant déjà des liens vers d'autres tables) et je voudrais pouvoir transformer, à tout moment, n'importe quel objet de type 'personne' en type 'responsable'.

Connaîtriez-vous un mécanisme permettant d'effectuer la "promotion" de l'objet 'personne' vers 'responsable' autrement qu'en supprimant l'objet initial 'personne' (et toutes ses relations) et en re-créant un nouvel objet 'responsable' avec les mêmes attributs, Id, relations, etc...

Merci d'avance,

Cédric

C'est une erreur commune de modélisation, un objet ne peut pas changer de type.
Si un objet change de type, alors il faut gérer ce type par délégation et non par héritage.
Si tu as opté pour une stratégie avec discriminator, tu as de la chance et devrais pouvoir gérer ce cas en JDBC (update sur la colonne discriminante).
Sinon il te faut coder une méthode de changement de type qui n'est pas toujours possible et qui peut être très lourde.
Un peu plus facile: la procédure stockées mais ça n'est toujours pas très propre...

Bon courage en tout cas.

Salut Anthony,

Je crois que je vais avoir de la chance, parce que nous utilisont effectivement des descriminants. Je devrais donc pour voir m'en tirer avec une requête SQL qui outrepasse Hibernate.

Pour ce qui est de la modélisation, je ne dis pas le contraire. Mais puisque nous utilisons une approche MDA et que notre analyste -qui crée le design UML- n'a pas connaissance des limitations inhérentes à Hibernate, ca ne lui paraît pas être une erreur conceptuelle.

En tout cas merci pour l'info parce que j'étais parti pour une solution beaucoup plus lourde.

Cédric

ça n'est pas une limitation d'hibernate... ;)
Pense en java pure, c'est impossible

A mon avis, c'est une erreur grave. Regarde à page 14 de

http://www.martinfowler.com/apsupp/roles.pdf

Dans ce cas "Responsable" est un rôle comme "Manager" et "Salesman".

Johan.

PS. La (doutable) solution que tu viens de presenter se trouve sur page 6.

en résumé, si tu en as la possibilité, modifie ta conception.

Je suis tout à fait d'accord avec le concept (rien à redire là-dessus). Ce que décrit Fowler est bien la généralisation du cas de figure.

Je signalerais juste que, dans notre contexte, la relation personne->role serait dégénérée puisqu'elle sera toujours de type one-to-one et non one-to-many (il n'y aura jamais d'autre "rôle" que responsable).

D'autre part l'utilisation de l'héritage nous permet aussi de garder l'avantage du polymorphisme (un responsable étant tjs une personne).

Pour terminer, un autre effet secondaire de l'héritage est que l'on peut se passer de l'ajout d'une table supplémentaire à notre modèle qui en contient déjà une sacrée quantité.

Merci encore pour vos remarques constructives.

Cédric

C'est une limitation de la modélisation object, pas d'hibernate. Ton analyste devrait sentir cette subtilité, sinon faut le virer ;-)