Salut
Pour plusieurs raisons, je pense qu'il faudrait proposer l'intégration
de ces deux outils populaires de migration dans Topia, sous forme des
services.
Je pense que c'est une plus-value pour ToPIA si on veut donner l'envie
de l'utiliser, un développeur est toujours content de pouvoir retrouver
ses marques.
Par ailleurs, je trouve qu'il y a un apport point de vue évolutivité de
ToPIA. En effet, l'actuelle implémentation du service de migration est
couplée à Hibernate et est assez difficile (il a besoin du mapping
hibernate chargé, donc on fait de la migration de schéma pour faire
marcher hibernate avec hibernate, y'a une histoire de serpent qui se
mord la queue). Là, il on se branche niveau SQL, donc avant que
Hibernate soit branché : ça me paraît moins dangereux. Si on veut
dégager hibernate un jour, la partie migration pourra rester inchangée.
Ensuite, y'a l'argument de réutiliser du code plutôt que de réinventer
la roue (on a des bugs non-résolus sur le service de migration).
Autre argument majeur (voir killer argument) c'est pour nos applis
libres (Pollen, Lima...). En effet, elles stockent des données dans des
bases SQL or, j'imagine que personne ne s'amuse à écrire les migrations
pour TOUS les SGBD. Liquibase propose un langage (XML :-() de
description de migration portable. On pourrait donc coder les migrations
en Liquibase et garantir que Pollen peut tourner sur un SGBD au choix
(car actuellement, malgré l'utilisation de Topia, c'est faux).
Après, faut toujours être prudent, on peut avoir des soucis si on a pas
la main dessus donc pour moi donc ça doit venir en complément du service
de migration actuel et non en remplacement (cas des applis lourdes).
Donc, êtes-vous favorable à l'intégration dans topia de services de
compatibilités ? Et êtes-vous favorable à l'utilisation de ces services
dans nos applis chorem/clients ?
--
Brendan Le Ny, Code Lutin
bleny(a)codelutin.com
(+33) 02 40 50 29 28
