You are not logged in.
Pages: 1
Bonjour tous!
J'ai relevé un bug ennuyeux, très ennuyeux provoquant une perte de donnée lors de l'install/mise à jour des données de glpi:
J'ai laissé le batch d'install migrer mes tables pour les mettre à niveau de la 0.71 rc2.
Le problème est qu'il tronque TOUS les enregistrement après un caractère accentué!
exemple:
avant le batch :
select contents from glpi_tracking where id=3278;
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| contents |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ¤¤¤¤¤¤¤¤¤¤¤¤ et ¤¤¤¤¤¤¤¤¤¤¤¤ sont "confirmées" et resteront au département ¤¤¤¤ au moins jusqu'à fin octobre 2008.
Elles sont sensées faire le même travail que ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤ |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
après le batch :
select contents from glpi_tracking where id=3278;
+------------------------------------------------------+
| contents |
+------------------------------------------------------+
| ¤¤¤¤¤¤¤¤¤¤¤¤ et ¤¤¤¤¤¤¤¤¤¤¤¤¤sont "confirm |
+------------------------------------------------------+
Je n'ai pas encore eut le temps de vérifier la routine utilisée pour la mise à jour et si je trouve quelque chose d'intéressant je posterai sous ce message.
J'ai modifié mes tables afin qu'elle soient en full utf-8 avant la migration, ce qui est nécessaire dans mon cas car la base est partagée avec un autre outil.
Je pense que cela mérite de jeter un oeuil dessus afin de prévenir quelques mises à jour ... douloureuses!
Pour info, je migre depuis la version 68.3 vers la 0.71 rc2.
Et reste disponible pour des questions/manipulations.
D'avance merci pour la prise en compte
--
Benjamin PREISS
Last edited by benp (2008-06-13 14:18:09)
Offline
Bonjour tous,
le "bug" n'existe pas si la base est en full latin1 avant l'update ...
Bonne journée
Offline
full latin1 devrait etre son état normal. en 0.68.3
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
full latin1 devrait etre son état normal. en 0.68.3
Bonjour MoYo,
Je confirme que la base était en "full latin1" à l'origine, ce dont semblait s'accommoder glpi, mais avait des conséquence désastreuse lors de la lecture d'enregistrements ...
Je suis en train de regarder pour publier un patch avant l'appel du script de conversion pour tester l'encodage des tables .. ce qui serait synonyme de gain de temps lors de la mise à jour et éviterai aux personnes ayant eut les mêmes besoins que moi de se heurter à ce problème.
Lors du changement de charset de mes tables, j'étais passé par un dump de la base et un remplacement des occurrence charset=latin1 par charset=utf-8 suivit d'un réimport standard. Ce qui m'évitait de réencoder chaque caractère latin1 accentué par sa correspondance utf-8, le gain de temps se chiffre en précieuses minutes, mais je ne sait pas si cela est possible directement via php.
Par contre, existe-t-il un endroit ou est stocké le mcd par versions? Je redoute de vérifier les changement importants entre la 68.3 et la 71rc à tâtons ...
Bonne journée
--
Benjamin PREISS
Offline
Sur l'espace de dev vous pouvez accéder aux différentes versions de la structure de la db de GLPI.
Maintenant, je ne vois pas en quoi il s'agit d'un bug de GLPI.
Le script de mise à jour fait son travail sur la base des versions de DB qui correspondent aux versions officielles de GLPI.
Les versions antérieures à la 0.7 n'étaient pas full utf8 (situation batarde qui posait des problèmes). La mise à jour en 0.7 passe l'ensemble de la db en full utf8 en réalisant les conversions nécessaires.
JMD / Jean-Mathieu Doléans - Glpi-project.org - Association Indepnet
Apportez votre pierre au projet GLPI : Soutenir
Offline
Pages: 1