Salut, On a relancé cet aprem un vieux débat sur le service de migration. Comme on était en nombre réduit, je tente de synthétiser les différentes idées qui en sont ressorties, dîtes-nous ce que vous en pensez. J'ajoute également que j'ai pris certaines libertés dans la rédaction de ce mail sans consulter Brendan et Éric avec qui j'en ai discuté cet aprem. Proposition 1 : distinguer la version de l'application de la version de la base de données ========================================================================================== Exemple : * Version de l'application = 0.10.3 * Versions de la base = 4, 5, 6 La version de la base serait un entier tout con qu'on incrémente à chaque modification de base. Pour les versions ultérieures, on aurait : * Version de l'application = 0.10.4 * Versions de la base = 7 Puis : * Version de l'application = 0.11 * Versions de la base = 8, 9 etc... Proposition 2 : une classe de migration par version applicative =============================================================== La classe Java de migration (une seule par version applicative) serait donc un regroupement logique des migrations de version de base liées à cette version (applicative). Si je reprends l'exemple, la classe MachinCallbackV0_10_3contiendrait 3 méthodes, une pour chaque version de base (migrateToVersion4, migrateToVersion5 et migrateToVersion6). Cette classe serait responsable du choix de commit, au choix parmi : - après chaque version de base ; - après l'ensemble des versions de base qui constituent la version applicative. Au passage il serait cool de pouvoir aller lire et exécuter un fichier "migrateToVersion5.sql" en lieu et place d'un appel à la méthode Java. Proposition 3 : conserver un historique dans la table TMSVersion ================================================================ Aujourd'hui, la table TMSVersion ne contient qu'une seule et unique ligne avec une seule colonne qui contient "0.10.2": topiaId | version ----------------- xxxxx | 0.10.2 La nouvelle table contiendrait plus d'informations (exemple) : topiaId | dbVersion | appVersion | date | success | comment ---------------------------------------------------------------------------------- xxxxx | 5 | 0.10.3 | 21/11/2013 | true | suppr de la table machin xxxxx | 6 | 0.10.3 | 21/11/2013 | true | renommage colonne truc xxxxx | 7 | 0.10.4 | 25/12/2013 | false | ajout table pouette xxxxx | 7 | 0.10.4 | 26/12/2013 | true |ajout table pouette (retry) xxxxx | 8 | 0.11 | 01/01/2014 | true | - xxxxx | 9 | 0.11 | 01/01/2014 | true | - Pour connaître la version actuelle de la base, cette simple requête suffit : select max(dbVersion) from tmsversion where success is true; Ce ne sont que des propositions que j'ai présenté ici, il y aura certainement des points bloquants (migration pour les applis existantes, ...) auxquels nous nous attaquerons si ces propositions conviennent au plus grand nombre. À vous. Cordialement, Arnaud