Vérification du schéma de la base de données


Si vous avez mis à jour votre site Moodle depuis de nombreuses versions (majeures), il est (fort) possible que des différences apparaissent dans la définition des tables (le "schéma") de votre base de données et la version que vous obtiendriez en créant un nouveau site. Ceci est lié à des (petites) erreurs dans les scripts de mise à jour. La plupart de ces différences ne sont pas gênantes, mais certaines peuvent entrainer des erreurs ou comportements étranges. Par exemple, si une valeur par défaut à été ajoutée à un champ, et n'a pas été répercutée dans les scripts de mise à jour, le code qui s'attend à une certaine valeur par défaut risque de ne pas fonctionner.

Démarche

La solution est, après une mise à jour (ou avant, si la mise à jour ne se fait pas correctement) de comparer le schéma de votre base de données de production avec une autre d'un site nouvellement créé (ou aucune mise à jour n'a été faite) en utilisant exactement le même code.

Il y a plusieurs façons de faire cela, mais nous allons surtout voir comment le faire en ligne de commande Unix.

Générer le fichier contenant les différences en ligne de commande Unix

  • Terminez la mise à jour (ou si elle n'a pas fonctionné, le faire avant)
  • Générez le schéma de la base de données de votre site récemment mis à jour (ou en production) avec les commandes suivantes :
   mysqldump -d -u root -p base-production >production.schema
  • Copiez le code de votre Moodle de production vers un autre emplacement (accessible via le web). Il est nécessaire que ce soit exactement la même version !
  • Créez une nouvelle base de données (vide), et un nouvel emplacement moodledata pour ce nouveau site, comme précisé dans la documentation d'installation de Moodle
  • Modifiez le fichier config.php pour utiliser la nouvelle base de données et le nouveau dossier moodledata, ou supprimez le et utilisez le script d'installation
  • Lancez le script d'installation pour générer (si besoin) le fichier config.php et la base de données (les identifiants administrateurs et nom de site n'ont pas d'importance)
  • Générez le schéma de la base de données de votre nouveau site avec les commandes suivantes :
   mysqldump -d -u root -p base-propre >clean.schema
  • Lancez la commande suivante pour trouver les différences :
   diff -u production.schema clean.schema >db.diff

Vous pouvez maintenant regarder votre fichier db.diff avec votre éditeur favori pour voir les différences.

NOTE : les explications ci-dessus s'appliquent aux base de données MySQL. Les autres types de bases de données possèdent certainement des fonctions équivalentes pour sortir uniquement le schéma. Par exemple PostgreSQL a la commande pg_dump. Le reste de cette démarche peut s'appliquer de façon équivalente.

Interpréter le fichier diff

Tout d'abord, voici un exemple (réel) :

    --
    -- Table structure for table `mdl_backup_config`
       @@ -129,11 +93,11 @@
        DROP TABLE IF EXISTS `mdl_backup_config`;
        CREATE TABLE `mdl_backup_config` (
   -  `id` int(10) unsigned NOT NULL auto_increment,
   +  `id` bigint(10) unsigned NOT NULL auto_increment,
      `name` varchar(255) NOT NULL default ,
      `value` varchar(255) NOT NULL default ,
       PRIMARY KEY  (`id`),
   -  UNIQUE KEY `name` (`name`)
   +  UNIQUE KEY `mdl_backconf_nam_uix` (`name`)
        ) ENGINE=MyISAM AUTO_INCREMENT=15 DEFAULT CHARSET=utf8 COMMENT='To store backup configuration variables';

Le fichier peut avoir plusieurs blocs de changements. Les lignes commençant par un - sont celles montrant les éléments à enlever et les lignes avec un + indiquent par quoi les remplacer (pour que la base de production soit propre). Ici, les int ont été remplacés par des bigint et le nom de la clé a changé. Ces éléments auraient du être modifiés par les scripts de mise à jour mais ne l'ont pas étés.

Trop de changements à gérer manuellement ?

Si vous avez de nombreux changements à prévoir, il sera utile d'utiliser un programme dédié vous permettant de synchroniser plus facilement votre ancienne base de données avec la nouvelle.

Par exemple MySQL Workbench pour les bases de données MySQL.

Si vous travaillez dans un environnement Unix/Linux en ligne de commande, le script Python Schema Sync propose un moyen simple et rapide de générer toutes les lignes de commandes à utiliser pour modifier votre base de données.

Devrais-je m'inquiéter ?

Les changements dans les types de champs (du moment qu'ils restent compatibles) et les noms des clés semblent être les différences les plus courantes et ne devraient pas poser de problème. Les éléments à regarder plus particulièrement sont ceux liés aux champs manquants et aux valeurs par défaut différentes.

Par contre, si vous êtes sur le point de mettre à jour vers Moodle 2.x, vous êtes certainement particulièrement concerné. En effet, afin que la mise à jour se fasse sans encombre, il est important de s'assurer qu'il n'y a pas de souci, et de corriger les éventuels problèmes avant de faire la mise à jour.

Voir aussi