R��union persistence =================== mercredi 27/02/2013 pr��sents Benoit, Kevin, Tony. Points �� aborder ---------------- - transmission du dev fait par Benoit sur la persistence - revoir le mod��le sur les lots - lister les modifications �� faire sur le mod��le - gestion des pi��ces-jointes Revu de ce qui a ��t�� fait et modification �� pr��voir --------------------------------------------------- S��rie de campagne ~~~~~~~~~~~~~~~~~ Plut��t que d'utiliser une sentinelle pour le champs commentaire, nous proposons d'avoir un commentaire obligatoire comme ��a on supprime une rustine du code. (voir http://forge.codelutin.com/issues/2064) Campagne ~~~~~~~~ Ajouter le PSFM pour la gestion de la s��rie partielle (SURVEY_PART, alphanumeric= true). (Vincent) Pour ce qui est des chefs de missions ou des responsables de salle de tri, il serait peut-��tre plus int��ressant de les sauver dans VesselPersonFeatures car cela parra��t plus adapter, �� voir si possible. On utiliserait alors l'utilisateur qui fait la synchro pour renseigner Person / Departement car cela semble bien plus adapt�� : il s'agit bien d'un membre du SIH et non pas d'une personne li�� �� un bateau (ou �� une camapgne). A valider par l'Ifremer. Les donn��es suppl��mentaires sont stoqu��es dans fishingTrip#comment. Op��ration de p��che ~~~~~~~~~~~~~~~~~~ La notion du num��ro de trait n'est pas pr��sent dans le mod��le mais on ne l'ajoute pas car on sait comment le g��rer. Il est calcul�� �� partir du num��ro du navire et si non pr��sent on utilise le rank order (uniquement pour les donn��es entr��es vi Allegro). Comme pour les chefs de mission et responsable de salle de tri, il faudrait utiliser le VesselPersonFeatures pour rentrer les saisisseurs. On se rend compte que ce qui est demand�� au niveau des onglets environnement et hydrologique ne fonctionne pas avec la persistence actuelle. en effet, autant pour l'onglet mise en ouevre de l'engin on peut tr��s bien les identifier (tout est d��vers�� dans la table GearUseFeatures), mais pour les deux autres ognelts tout va dans la table VesselUseFeatures et donc impossible de savoir dans quel onglet mettre. Le seul moyen de s'en sortir est l'utilisation du protocole, conjointement �� l'utilisation d'un quatri��me onglet *Autres...* qui permettra comme dans Allegro d'y ranger toutes les caract��ristiques non li��es �� lamise en ouevre de l'engin dedans. On interdirait alors la fait de pouvoir ajouter directement dans les onglets Environnement et Hydrologique des nouvelles caract��ristiques (sauf si on passe par le protocole). Il faut que l'Ifremer valide le concept; on pourra mettre ��a en place pour la 1.1 si la d��cision est prise rapidemment. (voir http://forge.codelutin.com/issues/2065). on a rediscut�� aussi du fait qu'on retrouve toutes les caract��ristiques partout et c'est pas normal selon Benoit, par exemple sur l'onglet *Mise en oeuvre de l'engin* un discriminant simple sur le support engin) puet ��tre appliqu��. A voir avec l'Ifremer. A faire pour CodeLutin - Renommer *saisisseur* en *recorderPerson*. - V��rifier la sauvegarde des strates, sous-strates, localit��s (voir http://forge.codelutin.com/issues/2066) Les donn��es suppl��mentaires sont stoqu��es dans fishingOperation#comments. Lot ~~~ Revue de la gestion du mod��le d'��chantillonnage des lots. Le m��canisme de mise �� jour du mod��le d'��chantillonage doit activable (ou non) via une configuration. (voir http://forge.codelutin.com/issues/2067) Je ne pense que cela soit souhaitable �� utiliser par le client en production (en tout cas par l'utilisateur lambda) car fatalement cela g��re trop peu de cas pour ��tre viable sur le long terme, mais concernant le court terme c'est tr��s bien de pouvoir relire les donn��es CGFS. Si le m��canisme est activ�� alors on a a bien une modification des donn��es �� la lecture. A valider par l'Ifremer. Mensuration ~~~~~~~~~~~ L�� encore on pourrait limiter la liste des pmfm au discriminant lot, produit de lot. Il faut bien valider la sauvegarde des modifications (voir http://forge.codelutin.com/issues/2039). Pi��ce-jointe ~~~~~~~~~~~~ On peut avoir un service uniforme en utilisant le mod��le (ObjectType, MeasurementFile) pour la persistence des m��ta-donn��es. Pour le stockage physique des pi��ces-jointes, on utilisera le m��me m��canisme que celui mis en place par Christian (lui demander la nomenclature des chemins utilis��s). Pour le moment rien n'est pr��vu pour la synchro, nous proposons de fournir une zip avec l'ensemble des pi��ces-jointes connues dans la base). Gestion des caches ~~~~~~~~~~~~~~~~~~ Le cache sur les r��f��rentiels doit bien fonctionner ainsi que celui sur les lots. Il faut imp��rativement qu'ils soient efficaces pour la version 1.1, Benoit g��re ��a avant vendredi (apr��s il est en vacances :)). On les aura donc pour la version 1.0.2. Modifications du mod��le ----------------------- Il faut nous dire comment on peut proc��der (Codelutin), le temps nous a manqu�� hier soir pour finir d'aborder le point. Ce qui a ��t�� d��velopp�� par Beno��t fonctionne mais n'est pas perein sur le long terme, il faudrait prendre les d��cisions qui vont bien, tout en sachant l'inertie de modification du mod��le et les contraintes (et la volont��) d'avoir les donn��es saisi��es dans Tutti utilisables dans H2. A rediscuter avec l'Ifremer rapidemment.