Bonjour les Lutins, Sire, on en a gros.... Posons le contexte : Le diagramme suivant représente le coeur de notre application tel que Florian nous a aider a le faire. On s’interessera particulierement a la relation Workstation -> Flow. http://www.nomaka.fr/img/UML_Avant.png Nous avons donc un contenant "Workstation" qui contient un contenu "Flow" Notre premier code de création de Flow dans une Workstation est le suivant. WorkstationDAO ws_dao=EasyFlowDAOHelper.getWorkstationDAO(transaction); context.prepareTopiaId(Workstation.class, pWorkstation); FlowDAO flow_dao=EasyFlowDAOHelper.getFlowDAO(transaction); Flow newFlow = flow_dao.create( ,Flow.PROPERTY_BEGIN, pDate ,Flow.PROPERTY_RATIO,1); workstation.addFlow(newFlow); // Nous considerions que le Flow etait lie a la workstation ici ws_dao.update(pWorkstation); transaction.commitTransaction(); Nous nous assurions que les donnees etaient bien presentes par le chargement de la workstation par son nom puis du Flow par son TopiaID. Seulement lorsque nous avons voulu charger une workstation et tout les flows qui lui sont lies il n’y avait aucun flow associes a la workstation. Voici la requete TopiaQuery qui nous permet de recuperer la workstation et ses Flows : WorkstationDAO wsDAO = EasyFlowDAOHelper.getWorkstationDAO(transaction); TopiaQuery wsQuery = wsDAO.createQuery("W"); wsQuery.addEquals(Workstation.PROPERTY_NAME,wsName); wsQuery.addLoad(Workstation.PROPERTY_FLOW); Workstation workstation = wsDAO.findByQuery(wsQuery); Nous avons alors remis en cause le diagramme precedent et nous avons modifie la liaison Workstation / Flow comme sur le diagramme suivant : http://www.nomaka.fr/img/UML_Apres.png ce qui nous donne une nouvelle fonction de creation du flow comme suit : WorkstationDAO ws_dao=EasyFlowDAOHelper.getWorkstationDAO(transaction); context.prepareTopiaId(Workstation.class, pWorkstation); FlowDAO flow_dao=EasyFlowDAOHelper.getFlowDAO(transaction); Flow newFlow = flow_dao.create( Flow.PROPERTY_WORKSTATION,pWorkstation // ici on se dit que cette fois, nous avons bien la relation.... ,Flow.PROPERTY_BEGIN, pDate ,Flow.PROPERTY_RATIO,1); pWorkstation.addFlow(newFlow); ws_dao.update(pWorkstation); transaction.commitTransaction(); Nous utilisons la meme methode de chargement qui ne nous renvoie toujours pas ce qu’il nous faut... La requete que nous avons reelement besoin est plus restrictive et utilise un fetch mais ne recupere pas non plus le flow (logique en fait) : WorkstationDAO wsDAO = EasyFlowDAOHelper.getWorkstationDAO(transaction); TopiaQuery wsQuery = wsDAO.createQuery("W"); wsQuery.addEquals(Workstation.PROPERTY_NAME,wsName); wsQuery.addFrom(Flow.class,"F"); wsQuery.addLeftJoin("W."+Workstation.PROPERTY_FLOW, null, true); wsQuery.addWhere("F."+Flow.PROPERTY_END+" IS NULL"); Workstation workstation = wsDAO.findByQuery(wsQuery); Nous pensons que nous avons un probleme avec nos relations dans notre diagramme UML mais nous ne voyons pas ce qui ne vas pas... Si c’est un probleme de code, nous ne voyons pas non plus... Quelqu’un aurait une idee ? Julien & Guillaume Nomaka
On Tue, 28 Sep 2010 09:11:33 +0200 Julien NICOLAS <nicolas.julien.cg@gmail.com> wrote:
Bonjour les Lutins,
Sire, on en a gros....
Je préviens tout de suite, je ne vais pas répondre à la question :)
Posons le contexte : Le diagramme suivant représente le coeur de notre application tel que Florian nous a aider a le faire. On s’interessera particulierement a la relation Workstation -> Flow.
Je préfère franchement, ce 1er diagramme, car il faut éviter au maximum (proscrire ?) les relations bidirectionnelles.
Nous avons donc un contenant "Workstation" qui contient un contenu "Flow"
Notre premier code de création de Flow dans une Workstation est le suivant.
WorkstationDAO ws_dao=EasyFlowDAOHelper.getWorkstationDAO(transaction); context.prepareTopiaId(Workstation.class, pWorkstation);
euh, a quoi ça sert cette ligne et d'où sort cet objet context ?
FlowDAO flow_dao=EasyFlowDAOHelper.getFlowDAO(transaction); Flow newFlow = flow_dao.create( ,Flow.PROPERTY_BEGIN, pDate ,Flow.PROPERTY_RATIO,1);
ouaih, les goûts et les couleurs, mais personnellement je préfère autant les set que ce create. Car la compile ne peut pas aider à détecter les erreurs. Et si on utilise les set, je pense qu'il faut faire un flow_dao.update(newFlow) en plus.
workstation.addFlow(newFlow); // Nous considerions que le Flow etait lie a la workstation ici ws_dao.update(pWorkstation); transaction.commitTransaction();
et surtout après le commit j'aurais été voir dans la base ce qui a été enregistré réellement.
Nous nous assurions que les donnees etaient bien presentes par le chargement de la workstation par son nom puis du Flow par son TopiaID.
Ok, mais je préfère tout de même regarder dans la base pour bien comprendre comment est fait le stockage. Y'a jamais rien de magique en informatique et si on le croit c'est une grosse erreur :)
Seulement lorsque nous avons voulu charger une workstation et tout les flows qui lui sont lies il n’y avait aucun flow associes a la workstation. Voici la requete TopiaQuery qui nous permet de recuperer la workstation et ses Flows :
WorkstationDAO wsDAO = EasyFlowDAOHelper.getWorkstationDAO(transaction); TopiaQuery wsQuery = wsDAO.createQuery("W"); wsQuery.addEquals(Workstation.PROPERTY_NAME,wsName); wsQuery.addLoad(Workstation.PROPERTY_FLOW); Workstation workstation = wsDAO.findByQuery(wsQuery);
euh, pourquoi se compliquer la vie et ne pas faire simplement WorkstationDAO wsDAO = EasyFlowDAOHelper.getWorkstationDAO(transaction); Workstation workstation = wsDAO.findByName(wsName); List<Flow> flows = workstation.getFlow(); En général toujours faire simple avant de rechercher la performance. Car souvent les goulots d'étranglements ne sont pas là où on les attendait. Donc ça sert à rien d'optimiser par du code compliqué quelque chose qui n'en à pas besoin.
Nous avons alors remis en cause le diagramme precedent et nous avons modifie la liaison Workstation / Flow comme sur le diagramme suivant :
http://www.nomaka.fr/img/UML_Apres.png
ce qui nous donne une nouvelle fonction de creation du flow comme suit :
WorkstationDAO ws_dao=EasyFlowDAOHelper.getWorkstationDAO(transaction); context.prepareTopiaId(Workstation.class, pWorkstation); FlowDAO flow_dao=EasyFlowDAOHelper.getFlowDAO(transaction); Flow newFlow = flow_dao.create( Flow.PROPERTY_WORKSTATION,pWorkstation // ici on se dit que cette fois, nous avons bien la relation.... ,Flow.PROPERTY_BEGIN, pDate ,Flow.PROPERTY_RATIO,1); pWorkstation.addFlow(newFlow);
mauvais design, double set dans les deux sens, super dur à maintenir la cohérence, et donc potentiellement de nombreux bug incompréhensible :(
ws_dao.update(pWorkstation); transaction.commitTransaction();
Nous utilisons la meme methode de chargement qui ne nous renvoie toujours pas ce qu’il nous faut...
La requete que nous avons reelement besoin est plus restrictive et utilise un fetch mais ne recupere pas non plus le flow (logique en fait) : WorkstationDAO wsDAO = EasyFlowDAOHelper.getWorkstationDAO(transaction); TopiaQuery wsQuery = wsDAO.createQuery("W"); wsQuery.addEquals(Workstation.PROPERTY_NAME,wsName); wsQuery.addFrom(Flow.class,"F"); wsQuery.addLeftJoin("W."+Workstation.PROPERTY_FLOW, null, true); wsQuery.addWhere("F."+Flow.PROPERTY_END+" IS NULL"); Workstation workstation = wsDAO.findByQuery(wsQuery);
Je ne cherche même pas à la comprendre celle là ;)
Nous pensons que nous avons un probleme avec nos relations dans notre diagramme UML mais nous ne voyons pas ce qui ne vas pas... Si c’est un probleme de code, nous ne voyons pas non plus...
Quelqu’un aurait une idee ?
non :) -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
participants (2)
-
Benjamin POUSSIN -
Julien NICOLAS