Problème de dump sur les tables comportants des index de longueur spécifiée #3260

Le contexte est le suivant : http://contrib.spip.net/GIS-4?debut_comments-list=`476655#forum476655

En résumé, depuis que la table spip_gis contient des index dont la longueur est spécifiée, le système de dump génère une erreur sur ces tables. Après pas mal de recherche, je suis remonté jusqu'à spip_mysql_show_table() (raison pour laquelle ce ticket est déclaré sur le core et non le plugin dump).

J'ai d'abord étudié ce qui se passe dans base_copier_table() de ecrire/base/dump.php :

http://core.spip.org/projects/spip/repository/entry/spip/ecrire/base/dump.php#L536

À ce niveau, dans $desc_source['key'] la longueur des index n'est pas renseignée. Si on compare le contenu des fichiers de cache des descriptions des tables, on observe que tmp/cache/sql_desc*.txt ne renseigne pas la longueur des index. Alors que tmp/cachesql_desc_dump*.txt est ok, la longueur des index y est présente.

Du coup, j'en suis remonté à sql_showtable(), et plus précisemment à spip_mysql_show_table() :

http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L754

Depuis phpmyadmin, un SHOW CREATE TABLE renvoie bien ce qu'il faut, ex :

CREATE TABLE `spip_gis` (
 `id_gis` bigint(21) NOT NULL AUTO_INCREMENT,
 `titre` text NOT NULL,
 `descriptif` text NOT NULL,
 `lat` double DEFAULT NULL,
 `lon` double DEFAULT NULL,
 `zoom` tinyint(4) DEFAULT NULL,
 `adresse` text NOT NULL,
 `pays` text NOT NULL,
 `code_pays` varchar(255) NOT NULL DEFAULT '',
 `region` text NOT NULL,
 `departement` text NOT NULL,
 `ville` text NOT NULL,
 `code_postal` varchar(255) NOT NULL DEFAULT '',
 PRIMARY KEY (`id_gis`),
 KEY `lat` (`lat`),
 KEY `lon` (`lon`),
 KEY `pays` (`pays`(500)),
 KEY `code_pays` (`code_pays`),
 KEY `region` (`region`(500)),
 KEY `ville` (`ville`(500)),
 KEY `code_postal` (`code_postal`),
 KEY `departement` (`departement`(500))
) ENGINE=MyISAM AUTO_INCREMENT=24 DEFAULT CHARSET=latin1

Il semble que la regex de la ligne 736 ne match pas la table spip_gis certainement à cause des (500) :

http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L736

Et du coup, on bascule sur le plan B, qui ne fait qu'un simple SHOW COLUMNS FROM ne contenant pas l'information de longueur des index :

http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L765

Wala où j'en suis ^^ Je ne sais pas si ce comportement est voulu, mais il pose un sacré problème pour les dumps.

Le contexte est le suivant : http://contrib.spip.net/GIS-4?debut_comments-list=`476655#forum476655 En résumé, depuis que la table spip_gis contient des index dont la longueur est spécifiée, le système de dump génère une erreur sur ces tables. Après pas mal de recherche, je suis remonté jusqu'à `spip_mysql_show_table()` (raison pour laquelle ce ticket est déclaré sur le core et non le plugin dump). J'ai d'abord étudié ce qui se passe dans `base_copier_table()` de ecrire/base/dump.php : http://core.spip.org/projects/spip/repository/entry/spip/ecrire/base/dump.php#L536 À ce niveau, dans `$desc_source['key']` la longueur des index n'est pas renseignée. Si on compare le contenu des fichiers de cache des descriptions des tables, on observe que tmp/cache/sql_desc*.txt ne renseigne pas la longueur des index. Alors que tmp/cachesql_desc_dump*.txt est ok, la longueur des index y est présente. Du coup, j'en suis remonté à `sql_showtable()`, et plus précisemment à `spip_mysql_show_table()` : http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L754 Depuis phpmyadmin, un `SHOW CREATE TABLE` renvoie bien ce qu'il faut, ex : <pre> CREATE TABLE `spip_gis` ( `id_gis` bigint(21) NOT NULL AUTO_INCREMENT, `titre` text NOT NULL, `descriptif` text NOT NULL, `lat` double DEFAULT NULL, `lon` double DEFAULT NULL, `zoom` tinyint(4) DEFAULT NULL, `adresse` text NOT NULL, `pays` text NOT NULL, `code_pays` varchar(255) NOT NULL DEFAULT '', `region` text NOT NULL, `departement` text NOT NULL, `ville` text NOT NULL, `code_postal` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`id_gis`), KEY `lat` (`lat`), KEY `lon` (`lon`), KEY `pays` (`pays`(500)), KEY `code_pays` (`code_pays`), KEY `region` (`region`(500)), KEY `ville` (`ville`(500)), KEY `code_postal` (`code_postal`), KEY `departement` (`departement`(500)) ) ENGINE=MyISAM AUTO_INCREMENT=24 DEFAULT CHARSET=latin1 </pre> Il semble que la regex de la ligne 736 ne match pas la table `spip_gis` certainement à cause des `(500)` : http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L736 Et du coup, on bascule sur le plan B, qui ne fait qu'un simple `SHOW COLUMNS FROM` ne contenant pas l'information de longueur des index : http://core.spip.org/projects/spip/repository/entry/spip/ecrire/req/mysql.php#L765 Wala où j'en suis ^^ Je ne sais pas si ce comportement est voulu, mais il pose un sacré problème pour les dumps.

Bon, une fois de plus je vais faire le job de redmine et lier le commit suivant à ce ticket...

http://core.spip.org/projects/spip/repository/revisions/21572

Merci qui ? :p

On avance, le patch ci-joint reporte r21572 pour la branche 3.0.

Résultat : l'import de dump fonctionne de nouveau sur la table spip_gis, mais comme l'indique Emmanuel dans son log, on ignore la longueur des index, ce qui fait qu'on perd les index dont la longueur est déclarée.

Peut-on faire mieux ou est-ce que cela est suffisant ?

Appliqué par commit r21633.
Statut changé à Fermé

ça devrait être bon (en principe) :)
Version cible mise à 3.1
Statut changé à Nouveau

Statut changé à Fermé

Super, je viens de tester en 3.1 avec GIS installé, et la table spip_gis est bien restauré avec ses index lors de l'import du dump :)

Est-ce qu'on reporte r21633 sur la branche 3.0 ?

Et hop, reporté en 3.0 par r21672 :)