Réalisation de la tâche 2890 (Benoît)
Salut Benoit, Je voudrais réaliser cette tâche dans Tutti. Dans quelle mesure puis-je avancer, as-tu releasé adagio ? Je peux te faire ça mais à condition que tout soit ok et que tu valides; soit dit en passant on pourrait peut-être passer sur une version un peu plus majeur, l'apport de la migration via liquidbase me parait une grosse fonctionnalité (3.4?), à toi de me confirmer. Plusieurs petites choses restent à faire il me semble avant une nouvelle release : - je ne vois rien dans le changelog du projet (https://forge.ifremer.fr/svn/sih-adagio/trunk/adagio/src/site/changes.xml). - j'ai tenté un build mais quelque chose n'a pas l'air de bien fonctionner sur le patch du fichier /hibernate.cfg.xml : j'obtiens <mapping resource="${entity-mappings.generated.hbm.relativePath}"/> ... Peux-tu me confirmer la marche à suivre pour mettr en place cette fonctionnalité ? (une petite doc autre que dans le bas du ticket serait un plus pour adagio ? peut-être existe-t-elle mais je ne sais pas où) Juste rajouter cette ligne dans le fichier conf.properties liquibase.should.run=true Dis-moi quand tu pourras me répondre / traiter / finaliser (what else ?), pour que de mon côté j'adapte mon planning par rapport à cette tâche. Idéalement je voudrais la finir en début de semaine prochaine. merci pour tes réponses, tony.
Salut Tony, j'ai ajouté une note au ticket http://forge.codelutin.com/issues/2890 Pour l'erreur de compile, j'ai testé sous windows et cela fonctionne... Ca doit être un bug de Ant sous Linux, avec task *propertyregex.* Toi qui maitrise Maven à fond, vois tu un autre moyen pour créer le fichier hibernate.cfg.xml ? Générer une cartouche AndroMDA me parait un peu lourd pour ca... l'autre moyen est que je commit le fichier hibernate.cfg.xml. D'autant qu'il doit être présent dans src/main/java/ pour que liquibase le prenne (bug de liquibase). Qu'en dis tu ? Pour la propriété "liquibase.should.run=true". cela signifie que la mise sera faite dès l'ouverture du contexte Spring... Du coup il n'y aura quasiment pas de risque d'avoir une BDD incompatible. Je ne suis même pas sûr que cela te soit utile de récupérer la version de la BDD. elle sera toujours la dernière, non ? Une autre solution est de demander à l'utilsiateur s'il souhaite mettre à jour sa base. en particulier lorsqu'il en importe une. a+ Benoit. Benoit LAVENIER *E-IS - Environmental Information Systems - www.e-is.pro* Téléphone : *09 53 24 41 20* / *06 62 86 37 82* Adresse : 10 place de l'Eglise, 53470 MARTIGNE SUR MAYENNE Email : benoit.lavenier@e-is.pro Fax : 09 58 55 73 50 Le 17 juillet 2013 16:33, Tony Chemit <chemit@codelutin.com> a écrit :
Salut Benoit,
Je voudrais réaliser cette tâche dans Tutti.
Dans quelle mesure puis-je avancer, as-tu releasé adagio ? Je peux te faire ça mais à condition que tout soit ok et que tu valides; soit dit en passant on pourrait peut-être passer sur une version un peu plus majeur, l'apport de la migration via liquidbase me parait une grosse fonctionnalité (3.4?), à toi de me confirmer.
Plusieurs petites choses restent à faire il me semble avant une nouvelle release :
- je ne vois rien dans le changelog du projet ( https://forge.ifremer.fr/svn/sih-adagio/trunk/adagio/src/site/changes.xml ).
- j'ai tenté un build mais quelque chose n'a pas l'air de bien fonctionner sur le patch du fichier /hibernate.cfg.xml :
j'obtiens <mapping resource="${entity-mappings.generated.hbm.relativePath}"/> ...
Peux-tu me confirmer la marche à suivre pour mettr en place cette fonctionnalité ? (une petite doc autre que dans le bas du ticket serait un plus pour adagio ? peut-être existe-t-elle mais je ne sais pas où)
Juste rajouter cette ligne dans le fichier conf.properties
liquibase.should.run=true
Dis-moi quand tu pourras me répondre / traiter / finaliser (what else ?), pour que de mon côté j'adapte mon planning par rapport à cette tâche. Idéalement je voudrais la finir en début de semaine prochaine.
merci pour tes réponses,
tony. _______________________________________________ Tutti-devel mailing list Tutti-devel@list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel
On Wed, 17 Jul 2013 18:20:30 +0200 Benoit Lavenier <benoit.lavenier@e-is.pro> wrote:
Salut Tony,
j'ai ajouté une note au ticket http://forge.codelutin.com/issues/2890
Pour l'erreur de compile, j'ai testé sous windows et cela fonctionne... Ca doit être un bug de Ant sous Linux, avec task *propertyregex.* Toi qui maitrise Maven à fond, vois tu un autre moyen pour créer le fichier hibernate.cfg.xml ? Générer une cartouche AndroMDA me parait un peu lourd pour ca... l'autre moyen est que je commit le fichier hibernate.cfg.xml. D'autant qu'il doit être présent dans src/main/java/ pour que liquibase le prenne (bug de liquibase). Qu'en dis tu ?
Je ne sais pas si c'est un bug du plugin ant ou la regex qui n'est pas compatible et quelque part je m'en fiche; ce qui m'interesse c'est d'avoir le bon fichier. Je serais plus pour que tu le commites (pour moi y'a déjà trop de script de patches...). (je donne ça en *expert maven* ;) qui n'aime vraiment pas les scripts ant). Si tu le peux le commiter en UTF-8 et sans fin de ligne windows ça serait génial ... (il y a une propriété svn pour ça que je t'avais donné il me semble, non?).
Pour la propriété "liquibase.should.run=true". cela signifie que la mise sera faite dès l'ouverture du contexte Spring... Du coup il n'y aura quasiment pas de risque d'avoir une BDD incompatible. Je ne suis même pas sûr que cela te soit utile de récupérer la version de la BDD. elle sera toujours la dernière, non ? Une autre solution est de demander à l'utilsiateur s'il souhaite mettre à jour sa base. en particulier lorsqu'il en importe une.
Dans Tutti, on est bien incapable de savoir ce qui est compatible ou pas (pas de persistence), donc tout vient de la base dirigée par adagio; on n'a donc pas d'autre choix que d'utiliser la dernière version de la base (et donc d'adagio). La méthode dont tu parles dans le ticket DatabaseSchemaDao.getSchemaVersion() donne la version de ma base ? - comment alors avoir la version cible ? (celle dans laquelle on doit migrer) ? - comment aussi savoir si je dois migrer ? api sur la comparaison des versions ? Pour l'interaction avec l'utilisateur, on pourrait alors lui afficher le message : Votre base de données est en version XXX, une migration vers la version YYY est nécessaire ? - oui pour migrer la base - annuler pour ne pas migrer (la base ne sera alors pas utilisable dans cette version du logiciel). Christian, peux-tu nous dire si cela te convient ? vois-tu une autre solution ? Benoit on peut peut-être s'apeller demain pour ça si possible. merci et bonne soirée à vous. tony.
On Thu, 18 Jul 2013 16:43:40 +0200 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
J'ai peut-être oublié des cas et on peut aussi en rediscuter si vous avez des remarques ou des questions.
Ça me parait bien couvrir tous les cas.
En particulier Vincent est ce que ça te parait compliqué pour Allegro Campagne ? Est ce qu'on autorise si la base a une version plus récente (option prise avec warning pour l'instant) ?
Merci pour vos retours.
Je ne sais toujours pas comment récupérer la version dite préconisée par le logiciel, j'ai bien compris comment avoir celle de la base via le travail de Benoît mais c'est tout. Il me faut cette information, sinon je peux pas traiter la demande. merci. tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Bonsoir Tony,
J'espère que tu vas bien.
J'ai ajouté une méthode *shouldUpdateSchema*() pour savoir si une mise à
jour est nécessaire, et une méthode getSchemaVersionIfUpdate pour connaitre
la version cible "prévue" pour adagio-core-allegro.
Pour déterminer s'il faut afficher les warning des cas "version base locale
> version application" il faut faire :
*if (getSchemaVersion.compareTo(getSchemaVersionIfUpdate()) > 0) {*
* // displayWarning*
*}*
En revanche, j'ai simplement testé le code rapidement. Pourras tu vérifier
si une fois intégrer en JAR dans tutti la
méthode getSchemaVersionIfUpdate().toString() renvoi bien une version
"3.2.3" ?
J'ai un doute avec la récupération dynamique par Spring des resources
fichiers... cf classe *Liquibase.java *qui parcours les fichiers
merci.
a+
Benoit.
Benoit LAVENIER
*E-IS - Environmental Information Systems - www.e-is.pro*
Téléphone : *09 53 24 41 20* / *06 62 86 37 82*
Adresse : 10 place de l'Eglise, 53470 MARTIGNE SUR MAYENNE
Email : benoit.lavenier@e-is.pro
Fax : 09 58 55 73 50
Le 18 juillet 2013 16:51, Tony Chemit <chemit@codelutin.com> a écrit :
> On Thu, 18 Jul 2013 16:43:40 +0200
> Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
>
> > J'ai peut-être oublié des cas et on peut aussi en rediscuter si vous
> avez des remarques ou des questions.
>
> Ça me parait bien couvrir tous les cas.
>
> > En particulier Vincent est ce que ça te parait compliqué pour Allegro
> Campagne ? Est ce qu'on autorise si la base a une version plus récente
> (option prise avec warning pour l'instant) ?
> >
> > Merci pour vos retours.
>
> Je ne sais toujours pas comment récupérer la version dite préconisée par
> le logiciel, j'ai bien compris comment avoir celle de la base via le
> travail de Benoît mais c'est tout.
>
> Il me faut cette information, sinon je peux pas traiter la demande.
>
> merci.
>
> tony.
>
>
> --
> Tony Chemit
> --------------------
> tél: +33 (0) 2 40 50 29 28
> email: chemit@codelutin.com
> http://www.codelutin.com
> _______________________________________________
> Tutti-devel mailing list
> Tutti-devel@list.forge.codelutin.com
> http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel
>
On Thu, 18 Jul 2013 19:09:17 +0200
Benoit Lavenier <benoit.lavenier@e-is.pro> wrote:
> Bonsoir Tony,
>
> J'espère que tu vas bien.
>
> J'ai ajouté une méthode *shouldUpdateSchema*() pour savoir si une mise à
> jour est nécessaire, et une méthode getSchemaVersionIfUpdate pour connaitre
> la version cible "prévue" pour adagio-core-allegro.
>
> Pour déterminer s'il faut afficher les warning des cas "version base locale
> > version application" il faut faire :
> *if (getSchemaVersion.compareTo(getSchemaVersionIfUpdate()) > 0) {*
> * // displayWarning*
> *}*
>
> En revanche, j'ai simplement testé le code rapidement. Pourras tu vérifier
> si une fois intégrer en JAR dans tutti la
> méthode getSchemaVersionIfUpdate().toString() renvoi bien une version
> "3.2.3" ?
> J'ai un doute avec la récupération dynamique par Spring des resources
> fichiers... cf classe *Liquibase.java *qui parcours les fichiers
Ok je regarde ça demain matin; par contre je ne vois pas la modification sur le fichier de configuration d'hibernate, un oubli ?
bonne soirée,
tony
Tony,
J'ai corrigé le pom.xml pour ne plus générer le fichier hibernate.cfg.xml
(par défaut).
Le fichier est bien sous SVN.
J'espère que tout fonctionnera... je pars en vacances ce soir et j'ai plein
d'autres choses à finir...
a+
Benoit LAVENIER
*E-IS - Environmental Information Systems - www.e-is.pro*
Téléphone : *09 53 24 41 20* / *06 62 86 37 82*
Adresse : 10 place de l'Eglise, 53470 MARTIGNE SUR MAYENNE
Email : benoit.lavenier@e-is.pro
Fax : 09 58 55 73 50
Le 18 juillet 2013 19:50, Tony Chemit <chemit@codelutin.com> a écrit :
> On Thu, 18 Jul 2013 19:09:17 +0200
> Benoit Lavenier <benoit.lavenier@e-is.pro> wrote:
>
> > Bonsoir Tony,
> >
> > J'espère que tu vas bien.
> >
> > J'ai ajouté une méthode *shouldUpdateSchema*() pour savoir si une mise à
> > jour est nécessaire, et une méthode getSchemaVersionIfUpdate pour
> connaitre
> > la version cible "prévue" pour adagio-core-allegro.
> >
> > Pour déterminer s'il faut afficher les warning des cas "version base
> locale
> > > version application" il faut faire :
> > *if (getSchemaVersion.compareTo(getSchemaVersionIfUpdate()) > 0) {*
> > * // displayWarning*
> > *}*
> >
> > En revanche, j'ai simplement testé le code rapidement. Pourras tu
> vérifier
> > si une fois intégrer en JAR dans tutti la
> > méthode getSchemaVersionIfUpdate().toString() renvoi bien une version
> > "3.2.3" ?
> > J'ai un doute avec la récupération dynamique par Spring des resources
> > fichiers... cf classe *Liquibase.java *qui parcours les fichiers
>
> Ok je regarde ça demain matin; par contre je ne vois pas la modification
> sur le fichier de configuration d'hibernate, un oubli ?
>
> bonne soirée,
>
> tony
> _______________________________________________
> Tutti-devel mailing list
> Tutti-devel@list.forge.codelutin.com
> http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel
>
On Fri, 19 Jul 2013 10:46:46 +0200 Benoit Lavenier <benoit.lavenier@e-is.pro> wrote:
Tony,
J'ai corrigé le pom.xml pour ne plus générer le fichier hibernate.cfg.xml (par défaut).
merdum j'étais moi en train de corrigé tes *scripts* ant car y'a des choses qui ne vont pas; en l'occurrence ça : si tu écris ça <propertyregex input="${entity-mappings.generated.dir.cleanPath}" regexp="\\" replace="/" property="entity-mappings.generated.dir.cleanPath" override="true"> et que rien ne matche la regex, alors la variable n'est pas settée (ce qui est le cas sous linux car on replace pas de \... Il faut alors écrire <propertyregex input="${entity-mappings.generated.dir.cleanPath}" regexp="\\" replace="/" property="entity-mappings.generated.dir.cleanPath" override="true" defaultValue="${entity-mappings.generated.dir.cleanPath}"/> La default value sera settée si la regex ne matche pas ;) Donc c'est pas un bug linux ;) mais une mauvaise utilisation de ta part. Il faudra mieux qu'on modifie alors le code pour que ça marhc epour les deux env (mais plus tard...)
Le fichier est bien sous SVN.
J'espère que tout fonctionnera... je pars en vacances ce soir et j'ai plein d'autres choses à finir...
hum tu reviens quand ? car j'ai pas trop envie de perdre mon temps en conjecture et en attente de ton retour de vacances si quelque chose ne fonctionne pas :( Il eut été préférable de nous le dire le jour même :(. Bon bah tanpis alors... Christian du coup, je préfère malheureusement reporter cette tâche au retour de vacances de Benoît si possible; je ne voudrais pas me perdre dans adagio (si quelque chose ne fonctionne pas évidemment). Bonne vacances (quand même) :D tony.
je reviens le 05/08. Pour le script, on voit ca à mon retour. N'hésites pas à m'appeler directement par tél, si besoin a+ Benoit LAVENIER *E-IS - Environmental Information Systems - www.e-is.pro* Téléphone : *09 53 24 41 20* / *06 62 86 37 82* Adresse : 10 place de l'Eglise, 53470 MARTIGNE SUR MAYENNE Email : benoit.lavenier@e-is.pro Fax : 09 58 55 73 50 Le 19 juillet 2013 11:56, Christian BONNET <Christian.Bonnet@ifremer.fr> a écrit :
Pas de problème pour reporter le ticket pour quand Benoît sera là. Maintenant que le fonctionnel est clair et tracé, c'est pour moi le plus important. Après la technique c'est du détail ;-) ...
[image: Site Ifremer] <http://www.ifremer.fr> Christian BONNET
Centre de Brest ZI de la pointe du diable CS 10070 - 29280 Plouzané Infrastructures Marines et Numériques Informatique et Données Marines Ingénierie des Systèmes d'Information
christian.bonnet@ifremer.fr www.ifremer.fr
Tel : +33 (0)2.98.22.46.16 Fax : +33 (0)2.98.22.46.44 Le 19/07/2013 11:46, Tony Chemit a écrit :
On Fri, 19 Jul 2013 10:46:46 +0200 Benoit Lavenier <benoit.lavenier@e-is.pro> <benoit.lavenier@e-is.pro> wrote:
Tony,
J'ai corrigé le pom.xml pour ne plus générer le fichier hibernate.cfg.xml (par défaut).
merdum j'étais moi en train de corrigé tes *scripts* ant car y'a des choses qui ne vont pas; en l'occurrence ça :
si tu écris ça
<propertyregex input="${entity-mappings.generated.dir.cleanPath}" regexp="\\" replace="/" property="entity-mappings.generated.dir.cleanPath" override="true">
et que rien ne matche la regex, alors la variable n'est pas settée (ce qui est le cas sous linux car on replace pas de \...
Il faut alors écrire
<propertyregex input="${entity-mappings.generated.dir.cleanPath}" regexp="\\" replace="/" property="entity-mappings.generated.dir.cleanPath" override="true" defaultValue="${entity-mappings.generated.dir.cleanPath}"/>
La default value sera settée si la regex ne matche pas ;)
Donc c'est pas un bug linux ;) mais une mauvaise utilisation de ta part.
Il faudra mieux qu'on modifie alors le code pour que ça marhc epour les deux env (mais plus tard...)
Le fichier est bien sous SVN.
J'espère que tout fonctionnera... je pars en vacances ce soir et j'ai plein d'autres choses à finir...
hum tu reviens quand ? car j'ai pas trop envie de perdre mon temps en conjecture et en attente de ton retour de vacances si quelque chose ne fonctionne pas :(
Il eut été préférable de nous le dire le jour même :(. Bon bah tanpis alors...
Christian du coup, je préfère malheureusement reporter cette tâche au retour de vacances de Benoît si possible; je ne voudrais pas me perdre dans adagio (si quelque chose ne fonctionne pas évidemment).
Bonne vacances (quand même) :D
tony. _______________________________________________ Tutti-devel mailing listTutti-devel@list.forge.codelutin.comhttp://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel
_______________________________________________ Tutti-devel mailing list Tutti-devel@list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel
On Thu, 18 Jul 2013 19:09:17 +0200 Benoit Lavenier <benoit.lavenier@e-is.pro> wrote:
En revanche, j'ai simplement testé le code rapidement. Pourras tu vérifier si une fois intégrer en JAR dans tutti la méthode getSchemaVersionIfUpdate().toString() renvoi bien une version "3.2.3" ? J'ai un doute avec la récupération dynamique par Spring des resources fichiers... cf classe *Liquibase.java *qui parcours les fichiers
Je confirme que cela ne fonctionne pas, j'ai corrigé ça. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Bonjour, Le mécanisme proposé me semble bon et nécessaire Les textes en vert me conviennent A+ Vincent Le 18/07/2013 16:43, Christian BONNET a écrit :
bonjour,
je suis reparti du besoin fonctionnel et des différents cas de figure (à priori).
J'ai repris le compte rendu initial fait par Erwan que j'ai complété par rapport à ce que Benoît à mis en oeuvre en précisant quels étaient les comportements fonctionnels à adopter.
J'ai peut-être oublié des cas et on peut aussi en rediscuter si vous avez des remarques ou des questions.
En particulier Vincent est ce que ça te parait compliqué pour Allegro Campagne ? Est ce qu'on autorise si la base a une version plus récente (option prise avec warning pour l'instant) ?
Merci pour vos retours.
PS : Erwan, à ton retour je te laisse voir où mettre ces infos pour que ça ne reste pas juste un mail ou une note (wiki ? Autre chose)
Christian
Site Ifremer <http://www.ifremer.fr> Christian BONNET
Centre de Brest ZI de la pointe du diable CS 10070 - 29280 Plouzané Infrastructures Marines et Numériques Informatique et Données Marines Ingénierie des Systèmes d'Information
christian.bonnet@ifremer.fr <mailto:christian.bonnet@ifremer.fr> www.ifremer.fr <http://www.ifremer.fr> Tel : +33 (0)2.98.22.46.16 Fax : +33 (0)2.98.22.46.44
Le 17/07/2013 18:34, Tony Chemit a écrit :
On Wed, 17 Jul 2013 18:20:30 +0200 Benoit Lavenier<benoit.lavenier@e-is.pro> wrote:
Salut Tony,
j'ai ajouté une note au tickethttp://forge.codelutin.com/issues/2890
Pour l'erreur de compile, j'ai testé sous windows et cela fonctionne... Ca doit être un bug de Ant sous Linux, avec task *propertyregex.* Toi qui maitrise Maven à fond, vois tu un autre moyen pour créer le fichier hibernate.cfg.xml ? Générer une cartouche AndroMDA me parait un peu lourd pour ca... l'autre moyen est que je commit le fichier hibernate.cfg.xml. D'autant qu'il doit être présent dans src/main/java/ pour que liquibase le prenne (bug de liquibase). Qu'en dis tu ? Je ne sais pas si c'est un bug du plugin ant ou la regex qui n'est pas compatible et quelque part je m'en fiche; ce qui m'interesse c'est d'avoir le bon fichier.
Je serais plus pour que tu le commites (pour moi y'a déjà trop de script de patches...). (je donne ça en *expert maven* ;) qui n'aime vraiment pas les scripts ant).
Si tu le peux le commiter en UTF-8 et sans fin de ligne windows ça serait génial ... (il y a une propriété svn pour ça que je t'avais donné il me semble, non?).
Pour la propriété "liquibase.should.run=true". cela signifie que la mise sera faite dès l'ouverture du contexte Spring... Du coup il n'y aura quasiment pas de risque d'avoir une BDD incompatible. Je ne suis même pas sûr que cela te soit utile de récupérer la version de la BDD. elle sera toujours la dernière, non ? Une autre solution est de demander à l'utilsiateur s'il souhaite mettre à jour sa base. en particulier lorsqu'il en importe une. Dans Tutti, on est bien incapable de savoir ce qui est compatible ou pas (pas de persistence), donc tout vient de la base dirigée par adagio; on n'a donc pas d'autre choix que d'utiliser la dernière version de la base (et donc d'adagio).
La méthode dont tu parles dans le ticket DatabaseSchemaDao.getSchemaVersion() donne la version de ma base ?
- comment alors avoir la version cible ? (celle dans laquelle on doit migrer) ? - comment aussi savoir si je dois migrer ? api sur la comparaison des versions ?
Pour l'interaction avec l'utilisateur, on pourrait alors lui afficher le message :
Votre base de données est en version XXX, une migration vers la version YYY est nécessaire ?
- oui pour migrer la base - annuler pour ne pas migrer (la base ne sera alors pas utilisable dans cette version du logiciel).
Christian, peux-tu nous dire si cela te convient ? vois-tu une autre solution ?
Benoit on peut peut-être s'apeller demain pour ça si possible.
merci et bonne soirée à vous.
tony. _______________________________________________ Tutti-devel mailing list Tutti-devel@list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel
-- Vincent BADTS Responsable qualité du SIH (Système d'Informations Halieutiques) IFREMER centre Atlantique Unité EMH (Ecologie et Modèles pour l'Halieutique) Tél : 33 2 40 37 40 53 (interne : 80 53) Fax : 33 2 40 37 40 38 www.ifremer.fr
participants (4)
-
Benoit Lavenier -
Christian BONNET -
Tony Chemit -
Vincent BADTS