Re: [Topia-users] Creer un objet contenu dans un autre.
J'ai vu que tu avais ajouter directement un attribut dans la classe sur le modele. Il est preferable d'utiliser une liaison entre les deux classes, Topia a quelque fois besoin de connaitre l'inverse (voir WARNING de validation lors de la compilation maven).
Si tu parles du FlowCurrent de Workstation, je l'ai fait oui.... Mon but est d'avoir l'adresse du flow courrant de la collection. Si je doit eviter de le mettre dans le modele, ou dois-je le mettre ? J'ai essaye de le declare dans le la classe WorkstationImpl mais cela n'a pas l'air de fonctionner (je n'ai pas fait de methode get/set ce qui peut etre la cause)
J'ai ajoute quelques commentaires et reparer le jeu de test directement dans le code.
Merci pour ca. J'ai suivi en supprimant le code obsolete, j'ai aussi modifie le modele en supprimant les methodes devenues inutiles et suivi les conseils indiques dans le code J'ai cree la methode stopWorkstation et j'ai maintenant une autre question. A terme j'aurai une multitude de flow pour ma workstation. Lorsque je charge la workstation, je ne charge pas les sous entités (le flow par exemple) Ensuite j'ajoute un flow lors du startWorkstation, le commit permet de valider la modification. Mais si jamais je supprime un flow de la collection de la workstation, que se passe-t-il ? j'imagine qu'il est supprime de la base. Mon probleme est que je ne souhaite avoir qu'un flow a la fois charge dans la workstation mais garder les entites flow creees dans la base... En suivant cette logique j'imagine le scenario suivant : - je cre un flow lors du "startWorkstation" - lors du "stopWorkstation", je renseigne la date de fin - je l'enregistre dans la base - je l'enleve de la collection de la workstation. Pour cela j'imagine faire un commit apres le stopWorkstation puis recharger la workstation pour n'avoir aucun flow de charge. J'ai bon ?
Il est preferable d'eviter de manipuler des transactions dans les entit?s. Mieux vaut utiliser le manager (?quivalent ? un service) qui contiendra en parametre la workstation :
public void startWorkstation(Workstation workstation, Date begin) { ... }
Je veux bien mais si tu pouvais me dire pourquoi cela est "preferable", ca pourrait m'aider à comprendre le fonctionnement. Merci encore, Julien NICOLAS Nomaka
Le Thu, 29 Jul 2010 15:07:12 +0200, Julien NICOLAS <jnicolas@nomaka.fr> a écrit : Désolé d'avoir mis un peu de temps pour répondre :)
J'ai vu que tu avais ajouter directement un attribut dans la classe sur le modele. Il est preferable d'utiliser une liaison entre les deux classes, Topia a quelque fois besoin de connaitre l'inverse (voir WARNING de validation lors de la compilation maven).
Si tu parles du FlowCurrent de Workstation, je l'ai fait oui.... Mon but est d'avoir l'adresse du flow courrant de la collection. Si je doit eviter de le mettre dans le modele, ou dois-je le mettre ?
En fait il faut bien le mettre dans le modèle mais comme une simple liaison UML entre la workstation et le flow (donc une deuxième en plus de celle pour avoir tous les flows).
J'ai cree la methode stopWorkstation et j'ai maintenant une autre question. A terme j'aurai une multitude de flow pour ma workstation. Lorsque je charge la workstation, je ne charge pas les sous entités (le flow par exemple) Ensuite j'ajoute un flow lors du startWorkstation, le commit permet de valider la modification. Mais si jamais je supprime un flow de la collection de la workstation, que se passe-t-il ? j'imagine qu'il est supprime de la base.
Effectivement si tu fais un commit après la suppression de la liste.
Mon probleme est que je ne souhaite avoir qu'un flow a la fois charge dans la workstation mais garder les entites flow creees dans la base... En suivant cette logique j'imagine le scenario suivant : - je cre un flow lors du "startWorkstation" - lors du "stopWorkstation", je renseigne la date de fin - je l'enregistre dans la base - je l'enleve de la collection de la workstation.
Pour cela j'imagine faire un commit apres le stopWorkstation puis recharger la workstation pour n'avoir aucun flow de charge. J'ai bon ?
En fait tu n'a pas besoin de l'enlever de la collection. Cette collection te servira d'historique pour des statistiques par exemple. Pour ton besoin il te suffit juste de ne manipuler que le flow courant, et donc le charger au besoin lors du get de la workstation. Hibernate fonctionne en lazy par défaut (chargement à la demande), donc ta collection de flow "historique" ne se chargera jamais sauf si tu le demande explicitement, donc tu es tranquille pour ton UI avec seul le flow courant de charger. Pour être bien précis, il te faut donc deux liaisons dans ton modèle UML : - Workstation 1 ---<> * Flow : collection "historique" - Workstation 1 ---<> 0..1 Flow : flow courant. Il te faudra ajouter le nom de l'attribut comme role du côté de la classe Flow, flowCurrent me semble approprié.
Il est preferable d'eviter de manipuler des transactions dans les entit?s. Mieux vaut utiliser le manager (?quivalent ? un service) qui contiendra en parametre la workstation :
public void startWorkstation(Workstation workstation, Date begin) { ... }
Je veux bien mais si tu pouvais me dire pourquoi cela est "preferable", ca pourrait m'aider à comprendre le fonctionnement.
En fait les entités seront manipulés comme de simples bean java dans l'UI et les appels de méthodes, souvent automatisés par le framework, ne te permettront pas de bien contrôler les accès base. Le mieux c'est d'utiliser les services (ou manager) pour les accès base, ainsi tu peut plus facilement les contrôler car tu sais qu'a chaque appel de service tu auras une transaction et donc une connexion physique avec la base.
Merci encore,
De rien, en espérant ne pas t'avoir embrouillé :)
Julien NICOLAS Nomaka
-- Florian Desbois <fdesbois@codelutin.com> SSLL Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 Réseau Libre-Entreprise
participants (2)
-
fdesbois -
Julien NICOLAS