Mise à jour et patch SQL : amélioration du mécanisme

Le fait que nous ayons dû travailler à plusieurs sur une méga-branche (gestion des heures) m'a fait prendre conscience de la frustration que les patches SQL et les changements de version génèrent.

Actuellement, il y a deux systèmes :

l'un, écrit en PHP sert à à faire les migrations depuis les versions antérieures
l'autre, écrit en SQL, sert au déploiement d'une version X

Les problèmes sont l'obligation de duplication du code pour les montées en version et le fait que les changements d'une version X sont noyés dans le patch SQL (il est nécessaire de copier un fichier précédent pour avoir une base complète).

Compte tenu du fait que nous avons pour projet de ne supporter que les versions jusqu'à N-2 à partir de 1.9+, nous pourrions imaginer un nouveau système comme suit :

Base : fichier de patch SQL de création de la base N-2
Incréments : chaque PR qui modifie la base créé un fichier de patch sous une forme numérique prévisible (X.Y) où les valeurs ne peuvent que croître de tel sorte que :
la BDD, elle, sait jusqu'à quel point elle a patché, l'installateur peut ainsi faire le diff et appliquer le reste

(ou alors des fichiers de patch préfixés par une date (ou un timestamp, pour éviter les problèmes de date), avec une date de dernier patch en base, je suis pas contrariant. L'essentiel étant l'idée d'incrément, le reste importe peu)

Sous ce format, on augmente la rapidité d'exécution des mises à niveau de version puisque les patches ne seront que du SQL et c'est beaucoup plus pratique pour les développements. La contrepartie c'est qu'une installation de zéro peut potentiellement être plus longue.

Doc : http://cipcnet.insa-lyon.fr/sqltut/nexen/innodb-checkpoints.html http://dev.mysql.com/doc/refman/5.7/en/binary-log.html

libertempo / web

Mise à jour et patch SQL : amélioration du mécanisme #174