Déjà, il a fallu augmenter mon programme : pour une raison qu'il faudra chercher dans les entrailles de 20six, mon ancien carnet utilise une mise en page particulière des notes, et celui de Samantdi une autre. L'analyseur qui extrait les notes, les commentaires, les dates et heures et les coordonnées des commentateurs a dû être modifié. Je fais mes tests sur une duplication du carnet de Samantdi sur ma plate-forme (c'est vraiment bien d'être totalement maître de son truc), ça roule, pas d'erreurs, tout se passe bien. Prêt pour le prime-time.

La procédure est un peu alambiquée :

  1. faire une sauvegarde de la base DC, par le plugin Mysql, et récupérer le fichier de sauvegarde,
  2. l'injecter dans une base de données associée à un Dotclear créé juste pour l'opération,
  3. lancer l'outil de récupération des notes 20six, qui va remplir cette base de données dupliquée
  4. si tout se passe bien, faire une sauvegarde de ce faux blog, toujours par le plugin Mysql, et récupérer le fichier,
  5. l'injecter dans le vrai blog, comme s'il s'agissait de la restauration d'une sauvegarde.

Voilà pour la théorie. Hier, nous avons fait une première tentative. Tout s'est bien déroulé jusqu'à l'ultime étape, la réinjection de la base dans le vrai Dotclear. Echec fatal, le fichier est trop gros, la décompression se passe mal. L'opération de restauration ne commençant même pas, la base initiale n'est pas touchée. Aujourd'hui, après diverses cogitations et la modification temporaire du plugin Mysql[1], je m'estime prêt à tester de nouveau aujourd'hui en début d'après-midi.

Tout se passe bien jusqu'à la dernière étape, la restauration de la fausse sauvegarde. Là, il faut savoir comment le fichier de sauvegarde/restauration est composé, pour savourer ma douleur. Pour chaque table :

  1. on détruit la table (DROP machin-chouette)
  2. on la recrée (CREATE TABLE machin-chouette...)
  3. on la remplit (INSERT INTO machin-chouette VALUES(...))

Evidemment, vous le voyez venir gros comme un camion, la création d'une des tables a échoué. Pour être exact, la création de la table dc_user échoué. Or, cette table est celle qui définit la liste des utilisateurs autorisés à agir sur le carnet. Donc, à 14:30 aujourd'hui, le blog de Samantdi est parti en vrille : impossibilité de s'y connecter, puisque l'une ou l'autre des requêtes pour afficher une page va interroger la table des rédacteurs. Cette table n'existant plus, la requête finissait en erreur pas très propre, et plouf un vilain message dans le navigateur, au lieu d'une belle page avec des jolis mots qui racontent des trucs intéressants.

J'ai pris 15 ans à ce moment. Bousiller mon propre carnet, déjà, ça me gonflerait sévère. Ce ne serait pas très grave, puisqu'ayant le contrôle complet de la machine sur laquelle il tourne, je peux remonter tout ce que je veux. Par contre, bousiller le carnet d'une amie, qui fonctionne sur une machine à laquelle je n'ai aucun accès si ce n'est au travers d'un navigateur... Panique à bord.

Je vous passerai les détails scabreux de mes manipulations frénétiques. Le carnet est revenu en ligne à 15:15, et j'ai pu respirer de nouveau. Et, ayant pigé le problème, j'ai modifié la procédure opératoire, et ai fini par boucler l'opération d'injection des archives. Tout est donc bien qui finit bien.

Toutefois, je conseillerai une première modification du plugin Mysql : avant toute chose, qu'il vérifie que la version de la base de données sur laquelle on restaure une sauvegarde est compatible avec celle sur laquelle la sauvegarde a été faite. Et, à terme, une reprise totale de ce plugin, qui est sympa pour faire joujou mais constitue, en l'état, un extraordinaire outil pour bousiller son blog (même si c'est clairement indiqué, on a tendance à sous-estimer ce genre d'avertissements).

Notes

[1] Pour qu'il sache restaurer une sauvegarde déjà présente dans le répertoire share/mysql, où elle aura été placée par un transfert ftp.