[spip-dev] mise à jour de SPIP 2.1 bloquée en 15830

Dev
1

J’ai mis à jour un site par SVN sur la branche 2.1, et l’espace privé tourne en boucle sur le message "#### la procédure de mise à jour doit être lancée afin d’adapter la base de données à la nouvelle version de SPIPvérification faite je suis bloqué sur le commit http://core.spip.org/projects/spip/repository/revisions/19856

mais je ne comprends pas ce qui se passe : ecrire/inc_version indique 15830, maj/svn10000.php contient bien l’appel pour 15830, mais dans spip_meta je reste bloqué sur 15829.

any idea?

– Fil

2

Salut,

2012/11/14 Fil <fil@rezo.net>

J’ai mis à jour un site par SVN sur la branche 2.1, et l’espace privé tourne en boucle sur le message "#### la procédure de mise à jour doit être lancée afin d’adapter la base de données à la nouvelle version de SPIPvérification faite je suis bloqué sur le commit http://core.spip.org/projects/spip/repository/revisions/19856

mais je ne comprends pas ce qui se passe : ecrire/inc_version indique 15830, maj/svn10000.php contient bien l’appel pour 15830, mais dans spip_meta je reste bloqué sur 15829.

any idea?

– Fil

Ca va pas beaucoup t’aider mais je ne reproduis pas que ce soit des 2.1 avec mysql ou sqlite3.

3

j'ai eu le même problème récemment.
la création de la table spip_test ne passe apparament pas
(erreur mysql visible dans les logs).

le CREATE TABLE IF NOT EXISTS finit en erreur et en allant fouiller
dans mes fichiers de table mysql, il apparait qu'un spip_test.frm
orphelin (sans .MYD ni .MYI associés) existe encore alors même que
cette table était censé avoir été supprimée.

aprés destruction effective de ce spip_test.frm par un
DROP TABLE IF EXISTS bien senti, la mise à jour de la base de donnée
a pu être menée à terme.

4

Merci denisb de m’avoir mis sur la piste ; une erreur SQL bloquait en effet la création de spip_test, et donc l’upgrade échouait.

En fouillant, c’est parce que la meta “charset_sql_base” était réglée sur “utf-8” alors que MySQL attend “utf8” (sans tiret !). D’où l’erreur :

Unknown character set: ‘utf’ - CREATE TABLE IF NOT EXISTS base.spip_test (

a int) DEFAULT CHARACTER SET utf-8 COLLATE utf8_general_ci

la solution que j’ai trouvée : plaquer utf-8 sur utf8 dans la query. Mais est-ce la bonne solution ?

Index: ecrire/req/mysql.php

5

Cédric pense que c’est parce que j’ai dû mettre à la main ‘utf-8’ au lieu de ‘utf8’ lors d’un précédent bidouillage de la base, ce qui est bien possible. Donc pas de commit, mais problème à garder en mémoire pour le cas où on retombe dessus.