ToPIA Migration Service est un module ToPIA chargé d'effectuer la migration +d'une base de données existante sans perte de données.
+Ce service doit disposer de quelques proprietés de configuration pour effectuer +la migration d'une base de données.
+Ces proprietés sont fournit au service via un TopiaContext et font donc partie +de la configuration de l'application.
++hibernate.dialect=org.hibernate.dialect.HSQLDialect +hibernate.connection.username=sa +hibernate.connection.password= +hibernate.connection.driver_class=org.h2.Driver + +topia.persistence.directories=directory1,directory2 +topia.persistence.classes=classImpl1,classImpl2 +topia.persistence.properties.file=??? ++
Ces informations servent à créer une configuration hibernate (qui contient les +informations de connexion et les mappings de l'application).
+Les lignes commencant par "hibernate" sont spécifiques à hibernate et au type de +base de données utilisé. Les lignes suivantes sont spécifiques à ToPIA mais +contiennent les mappings indispensable pour créer le schéma de la base de +données après migration.
+La configuration doit contenir une propriété :
++topia.service.migration.mappingsdir=oldmappings ++
qui spécifie le répertoire de recherche des anciens mappings.
+Ce dossier contient ensuite un sous dossier par version (nommé VX, X étant la +version), avec pour chaque dossier, l'ensemble des mappings hibernate de cette +version.
+Exemple ::
++oldmappings/ + V1/ + Class1.hbm.xml + Class2.hbm.xml + Class3.hbm.xml + V2/ + Class1.hbm.xml + Class2New.hbm.xml + Class3.hbm.xml + V2.2/ + Class2.hbm.xml + Class3.hbm.xml + Class4New.hbm.xml ++
La configuration doit contenir une propriete :
++topia.service.migration.version=3.5.1 (example) ++
Cette proprietés renseigne la version courante de l'application.
+Ce module étant un service ToPIA, il doit être activé pour pouvoir s'exécuter.
+Il se commence par se connecter au SGBD, vérifie si les versions diffèrent, et +effectue la migration si besoin.
+Pour savoir comment migrer le données, le développeur utilisant le module de +migration doit produire des classes Java de migration (une par classe nécéssitant +une modification et par version).
+Ces classes doivent :
+hériter de la classe AbstractMigration ou de l'interface Migration
+se trouver dans le même package que les classes d'implémentation référencées +par les mappings
+respecter une convention de nommage de la forme +MigrationClassVnVm où:
+Exemple, pour migrer une Personne d'une version 2 Ã 2.1: +MigratePersonneV2V2_1.java
+Note: les "." étant interdits dans le nom de fichier, ils sont remplacés par le +caractère "_".
+Ensuite, chaque classe doit :
+Exemple :
+Ici, la modification porte sur la transformation de l'attribut timestampNaissance +de la classe domaine.Personne en une nouvelle table domaine.Naissance, effectée +dans le changement de la version 1 à la version 2 :
+
+// migrateFrom()
+public ProxyClass migrateFrom() {
+ return new SimpleProxyClass("domaine.Personne");
+}
+
+// migrate(MapAdapter, MapHelper)
+public void migrate(MapAdapter map, MapHelper helper) {
+
+ // map d'entree vide, conversion du timestamp
+ // en jour, mois, annee
+ try {
+ Long timestamp = (Long) map.getOldValue("timestampNaissance");
+ Calendar c = Calendar.getInstance();
+ c.setTimeInMillis(timestamp);
+ map.setValue("jour", c.get(Calendar.DAY_OF_MONTH));
+ map.setValue("mois", c.get(Calendar.MONTH));
+ map.setValue("annee", c.get(Calendar.YEAR));
+ } catch (ExceptionAttributeUndefined e) {
+ e.printStackTrace();
+ }
+}
+
+Donc cette classe :
+