Bonjour à tous, Le topiaCreateDate est désormais devenu un timestamp sur la version SNAPSHOT du trunk (2.3.0) : http://nuiton.org/issues/show/177 Le mapping hibernate a donc changé pour cette attribut, peut être cela va t'il influencer les migrations des bases ? A voir avec Topia-Migration. Cordialement, Florian
Le Tue, 29 Dec 2009 17:17:05 +0100, Florian Desbois <fdesbois@codelutin.com> a écrit :
Bonjour à tous,
Le topiaCreateDate est désormais devenu un timestamp sur la version SNAPSHOT du trunk (2.3.0) : http://nuiton.org/issues/show/177
Le mapping hibernate a donc changé pour cette attribut, peut être cela va t'il influencer les migrations des bases ? A voir avec Topia-Migration.
donc toutes les applications sur topia-3.0 devront écrire une nouvelle version de migration de base, je te le confirme. Dès qu'un mapping hibernate change => schema de base change => incrémente de la version du modèle (et de la base donc).
Cordialement,
Florian
_______________________________________________ Topia-devel mailing list Topia-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/topia-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 29/12/2009 17:17, Florian Desbois a écrit :
Bonjour à tous,
Salut,
Le topiaCreateDate est désormais devenu un timestamp sur la version SNAPSHOT du trunk (2.3.0) : http://nuiton.org/issues/show/177
Le soucis ici, est que la migration concerne toutes les entités de la base de données. Cela peut être un peu long a écrire. Mais malgré le changement de type du champs, il n'y a pas perte de données (testé sur h2). Une autre solution simple, pour éviter la migration est d'ajouter un tagvalue pour pouvoir rétablir le fonctionnement précédent. Par exemple : un tagvalue "topiadatetype" sur le modèle avec comme valeur par défaut "timestamp". -- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
Le 04/01/2010 09:50, Eric Chatellier a écrit :
Le 29/12/2009 17:17, Florian Desbois a écrit :
Salut,
Le topiaCreateDate est désormais devenu un timestamp sur la version SNAPSHOT du trunk (2.3.0) : http://nuiton.org/issues/show/177
Il n'y a finalement aucune migration à faire. Les schémas existant ont simplement une date sans heure dans la base.
-- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
Le Tue, 05 Jan 2010 16:05:34 +0100, Eric Chatellier <chatellier@codelutin.com> a écrit :
Le 04/01/2010 09:50, Eric Chatellier a écrit :
Le 29/12/2009 17:17, Florian Desbois a écrit :
Salut,
Le topiaCreateDate est désormais devenu un timestamp sur la version SNAPSHOT du trunk (2.3.0) : http://nuiton.org/issues/show/177
Il n'y a finalement aucune migration à faire. Les schémas existant ont simplement une date sans heure dans la base.
sauf si tu veux être cohérent entre ton mapping hibernate et ton schéma de base... concernant l'écriture d'une telle migration, tu disais auparavant que cela allait très fastidieux et je ne suis pas d'accord : dans les DAOHelper il y a une énumération pour toutes les entités gérées par le DAOHelper, donc il suffit de boucler sur l'énumération. Au final l'écriture d'un telle migration doit prendre au moins 10 minutes... -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Wed, 6 Jan 2010 09:26:50 +0100 Tony Chemit <chemit@codelutin.com> wrote:
sauf si tu veux être cohérent entre ton mapping hibernate et ton schéma de base...
Je ne vois pas vraiment le probleme, les vielles bases continuent a fonctionner, et les nouvelles auront l'info de l'heure en plus. Ce n'est pas genant pour moi. Et je pense que c presque mieux qu'une migration.
concernant l'écriture d'une telle migration, tu disais auparavant que cela allait très fastidieux et je ne suis pas d'accord :
dans les DAOHelper il y a une énumération pour toutes les entités gérées par le DAOHelper, donc il suffit de boucler sur l'énumération. Au final l'écriture d'un telle migration doit prendre au moins 10 minutes...
erreur, si tu fais ca, ca marche pas lorsque tu ajoutes une entite, car tu vas migrer une entite nouvelle qui ne doit pas l'etre. Donc prendre la liste a cette endroit la oui, mais la copier coller pour que le script de migration soit fixe dans le temps. Mais je me repete, je pense que si ca marche sans probleme sans migration, il vaut mieux ne pas faire de migration seulement pour ca. -- 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
Le mercredi 06 janvier 2010 à 16:57 +0100, Benjamin POUSSIN a écrit :
Je ne vois pas vraiment le probleme, les vielles bases continuent a fonctionner, et les nouvelles auront l'info de l'heure en plus.
En fait, le schema de base ne change pas pour une colonne existante, donc topiaCreateDate restera une date même si le mapping indique un timestamp. L'évolution sera prise en compte pour une nouvelle base. A moins de faire la migration manuelle...
Le mercredi 06 janvier 2010 à 17:10 +0100, Florian Desbois a écrit :
Le mercredi 06 janvier 2010 à 16:57 +0100, Benjamin POUSSIN a écrit :
Je ne vois pas vraiment le probleme, les vielles bases continuent a fonctionner, et les nouvelles auront l'info de l'heure en plus.
En fait, le schema de base ne change pas pour une colonne existante, donc topiaCreateDate restera une date même si le mapping indique un timestamp.
L'évolution sera prise en compte pour une nouvelle base. A moins de faire la migration manuelle...
Ok je sors, c'est ce que t'avais dit...
_______________________________________________ Topia-devel mailing list Topia-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/topia-devel
participants (4)
-
Benjamin POUSSIN -
Eric Chatellier -
Florian Desbois -
Tony Chemit