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

Closed
opened 8 years ago by b_b · 7 comments
b_b commented 8 years ago
Owner

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.
b_b commented 8 years ago
Poster
Owner

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

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
b_b commented 8 years ago
Poster
Owner

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 ?

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 ?
Owner

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

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

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

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

Statut changé à Fermé

**Statut changé à Fermé**
b_b commented 8 years ago
Poster
Owner

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 ?

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 ?
b_b commented 8 years ago
Poster
Owner

Et hop, reporté en 3.0 par r21672 :)

Et hop, reporté en 3.0 par r21672 :)
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.