Le Wed, 11 Aug 2010 10:23:44 +0200, Julien NICOLAS <jnicolas@nomaka.fr> a écrit :
Bonjour a tous, [...]
Pour mieux expliquer mon probleme, j'ai une entite workstation contenant une collection de Flow. Dans cette entite workstation j'ai mis un pointeur vers un objet de la collection de Flow.
La premiere action est de faire un "start" sur la workstation (creer un Flow dans la workstation avec une date de debut). Ensuite le temps passe et on fait un "stop" sur la workstation (changer renseigner la date de fin et calculer le temps passe).
Sur la premiere action, j'affecte a mon pointeur l'adresse de l'objet flow que j'ai cree avec les DAO. Sur la deuxieme j'utilise l'adresse de mon objet, renseigne les valeurs et fait un commit.
Mais rien ne change dans la base.... J'ai donc modifie le code pour charger mon objet Flow juste avant de modifier les valeurs... L'objet Flow current ne me sert que pour avoir le TopiaId mais je peux facilement m'en passer en utilisant le champ date de fin à null.
Je trouve cela dommage d'avoir à recharger l'entite a chaque fois que j'en ai besoin mais est-ce la bonne façon de penser ? Je me demande si ce n'est pas logique d'avoir a recharger l'entite car les donnees peuvent etre deja obsoletes et donc fausses.... Qu'en pensez-vous ?
En effet, il est souvent plus "safe" de recharger l'entité, la modifier au besoin et ensuite la sauver pour éviter les données corrompues (si plusieurs clients pour une même base par exemple).
Question : Ma workstation contient des evenements qui contiennent un flow. Je voudrais charger les evenements (normalement il ne doit y en avoir qu'un en cours à la fois) qui contiennent un flow avec une date de fin nulle. J'ai comme l'impression qu'il va me falloir utiliser une TopiaQuery mais je voudrais en etre sur. Si je n'en ai pas besoin, je ne vois pas comment coder cela... Un petit coup de pouce ?
En effet il te faudra sans doute une requête (donc TopiaQuery) avec jointure et tout ca. Un truc comme : flowDAO.createQuery("F"). // Ajout de l'entite Workstation au FROM addFrom(Workstation.class, "W"). // F doit etre contenu dans la collection de Flow de la workstation // en HQL : F IN elements(W.flow) addInElements("F", "W." + Workstation.Flow). // Recherche pour la workstation désiré addEquals("W", workstation). // Condition de nullité addNull("F." + Flow.END); La requête me semble adéquat pour ton problème, pas besoin de garder le flow courant. Cependant tu en aura surement besoin à l'affichage pour la date de début, peut-être garder une liste trié de flow par date dans la workstation, ainsi le dernier élément sera le courant que tu pourra directement modifier et sauver. Une méthode commune pour tout ton modèle fermera un flow en donnant une date de fin (il ne me semble pas nécessaire de connaitre l'entité qui lui est lié, ici la workstation). A noter qu'une workstation de longue date aura beaucoup de flow, donc un chargement non négligeable de l'intégralité des données de la liste, d'ou l'idée du double lien dans le modèle pour le flow courant. Je ne trouve pas si lourd que d'avoir deux liens entre chaque entité du modèle, le gain de chargement me semble vraiment important dans ce contexte d'historisation ! C'est vraiment une problématique métier, peut-être que quelqu'un à d'autres suggestions ? Benjamin par exemple :)
Si c'est une TopiaQuery je vais essayer de m'inspirer du code de Jean precedement poste et aller fouiller dans les sources du projet ifremer de Florian.
Il y a pas mal de documentation sur le site de topia : http://maven-site.nuiton.org/topia/topia-persistence/TopiaQuery.html
Reponse : Par rapport au precedent post, je voudrais dire a Florian qu'il ne m'a pas embrouille, au contraire je commence a bien voir comment tout cela s'articule. Meme si il me manque encore pas mal de bases sur l'utilisation des outils de topia. La connexion supplementaire vers l'entite Flow pour avoir le Flow courant ne me parait pas etre une bonne idee en fait. Car si je commence à coder comme cela, les autres entites auront aussi besoin de ce type de connexion et donc cela risque de rendre l'ensemble trop complexe pour le gain.... Mais je continu a creuser pour faire fonctionner l'ensemble avec le code le plus propre possible.
cool :)
Merci.
Julien Nomaka
-- Florian Desbois <fdesbois@codelutin.com> SSLL Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 Réseau Libre-Entreprise