Clé étrangère

Dans une installation normale de Dotclear, l’affichage de la commande SQL suivante :

SHOW CREATE TABLE `dc_category`;

Donne un résultat comme ci-dessous :

CREATE TABLE `dc_category` (
  `cat_id` bigint(20) NOT NULL,
  `blog_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `cat_title` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `cat_url` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `cat_desc` text,
  `cat_position` int(11) DEFAULT '0',
  `cat_lft` int(11) DEFAULT NULL,
  `cat_rgt` int(11) DEFAULT NULL,
  PRIMARY KEY (`cat_id`),
  UNIQUE KEY `dc_uk_cat_url` (`cat_url`,`blog_id`),
  KEY `dc_idx_category_blog_id` (`blog_id`),
  KEY `dc_idx_category_cat_lft_blog_id` (`blog_id`,`cat_lft`) USING BTREE,
  KEY `dc_idx_category_cat_rgt_blog_id` (`blog_id`,`cat_rgt`) USING BTREE,
  CONSTRAINT `dc_fk_category_blog` FOREIGN KEY (`blog_id`) REFERENCES `dc_blog` (`blog_id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Sur certaines instances anciennes de Gandi Hosting — a priori celles sur lesquelles Dotclear a été installé initialement avec une version 5.1 de MySQL —, ça donne plutôt cela :

CREATE TABLE `dc_category` (
  `cat_id` bigint(20) NOT NULL,
  `blog_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `cat_title` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `cat_url` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `cat_desc` text,
  `cat_position` int(11) DEFAULT '0',
  `cat_lft` int(11) DEFAULT NULL,
  `cat_rgt` int(11) DEFAULT NULL,
  PRIMARY KEY (`cat_id`),
  UNIQUE KEY `dc_uk_cat_url` (`cat_url`,`blog_id`),
  KEY `dc_idx_category_blog_id` (`blog_id`),
  KEY `dc_idx_category_cat_lft_blog_id` (`blog_id`,`cat_lft`) USING BTREE,
  KEY `dc_idx_category_cat_rgt_blog_id` (`blog_id`,`cat_rgt`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Vous voyez ? Il manque l’avant dernière ligne, celle-là même qui permet de gérer les suppressions et modifications en cascade.

Pourtant la clé existe bel et bien, je l’ai vérifié cet après-midi, mais comme Dotclear ne peut pas le savoir (vu son absence dans le résultat renvoyé par la requête SQL), il cherche encore et encore à recréer cette clé, et forcément ça couine !

Il aura fallu du temps pour mettre en évidence la raison de ce problème et à ce jour aucune solution viable n’a été trouvée pour corriger ça.

Toujours est-il que les utilisateurs concernés devront soit réinstaller une nouvelle version de Dotclear avec une nouvelle base, en espérant que ce n’est pas au niveau du serveur MySQL que le problème se trouve, soit continuer à utiliser l’actuelle, en prenant soin, et tant qu’il n’y aura pas de changement de structure de la base de données, d’installer un petit plugin que je viens de développer[1] et qui se chargera de faire les mises à niveau prévues au changement de version et de mettre à jour le numéro de version de Dotclear.

Je mets une version 0.1 de ce plugin que j’ai nommé growUp en pièce jointe de ce billet, histoire de le retrouver facilement.

Note

[1] Utilisable à partir de la prochaine version 2.9, y compris si l’update depuis une 2.8.2 ou 2.9-dev/-rNNNN s’est mal terminé.

Ajouter un commentaire

Les champs suivis d'un * sont obligatoires

Les commentaires peuvent être formatés en utilisant la syntaxe Markdown Extra.

Ajouter un rétrolien

URL de rétrolien : https://open-time.net/trackback/12753

Haut de page