Migrer un schéma quand la base est chez le client

Une migration PostgreSQL se lance une fois, sur une base que vous connaissez, avec une sauvegarde prise le matin et un œil sur les verrous. Si elle échoue, vous le savez dans la minute.

Une migration de base locale s'exécute dix mille fois, sur dix mille bases que vous n'avez jamais vues, au moment où l'utilisateur ouvre l'application, sur un téléphone à 8 % de batterie. Elle part de la version 3 chez l'un, de la version 9 chez l'autre. Si elle échoue, vous ne le savez pas ; vous recevez, trois jours plus tard, un message qui dit que l'application reste blanche.

Dès que des données vivent dans IndexedDB ou dans un SQLite embarqué, vous exploitez une flotte de bases de production sans accès d'administration. Les règles de migration côté serveur ne suffisent plus, il en faut de plus strictes.

Dix mille bases sans accès d'administration

Chaque différence avec le serveur retire un filet.

Toutes les versions coexistent. Sur le serveur, la base est à la version N ou N+1. Chez les clients, il y a au même instant des bases en version 3, 5, 8 et 11, parce que certains n'ont pas ouvert l'application depuis six mois.

Vous ne choisissez pas le moment. La migration démarre à l'ouverture, donc pendant que l'utilisateur attend, et le système peut tuer le processus au milieu.

Vous ne voyez pas les données. Les lignes malformées laissées par un bug de la version 4, corrigé depuis, sont toujours dans les bases qui sont passées par la version 4.

Le rollback n'existe pas. Vous pouvez republier l'ancienne version du code, mais pas ramener les bases déjà migrées.

La chaîne de migrations est permanente

La seule forme qui tient est une suite de migrations numérotées, appliquées dans l'ordre, chacune partant exactement de l'état laissé par la précédente. Avec IndexedDB, le navigateur fournit l'ancienne version et une transaction qui couvre toute la mise à niveau :