Index: topia-service/src/site/fr/rst/Migration.rst
diff -u topia-service/src/site/fr/rst/Migration.rst:1.3 topia-service/src/site/fr/rst/Migration.rst:1.4
--- topia-service/src/site/fr/rst/Migration.rst:1.3	Tue Nov 20 15:04:18 2007
+++ topia-service/src/site/fr/rst/Migration.rst	Fri Nov 23 14:28:39 2007
@@ -25,7 +25,6 @@
 
  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).
@@ -36,8 +35,8 @@
 données après migration.
 
 
-Configuration des mappings
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+Configuration des anciens mappings
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 La configuration doit contenir ces propriétés :
 
 ::
@@ -89,7 +88,7 @@
 interagir, par exemple, avec l'utilisateur et lui demander s'il faut migrer la
 base de données.
 
-Ces //callback// doivent implémenter MigrationCallbackHandler et se trouver dans
+Ces *callback* doivent implémenter MigrationCallbackHandler et se trouver dans
 la configuration:
 
 ::
@@ -114,6 +113,12 @@
 Il commence par se connecter au SGBD, vérifie si les versions diffèrent, et 
 effectue la migration si besoin.
 
+Dans le cas où la version ne peut pas être deterninée, il considère que le
+schema en base est en version V0 (les mppings de cette version doivent être
+fournit). Dans ce cas, il effectue en plus une détection des tables pour
+savoir si le schéma existe deja. S'il n'existe pas, il ne tente donc pas
+d'effetuer une migration.
+
 Classes de migration
 ~~~~~~~~~~~~~~~~~~~~
 Pour savoir comment migrer les données, le développeur utilisant le module de
@@ -125,17 +130,16 @@
 - hériter de la classe ``AbstractMigration`` ou de l'interface ``Migration``
 - se trouver dans un sous package des classes d'implémentation référencées
   par les mappings. Ce package doit se nommer VnVm où:
-  
+
   - *n* est la version de départ de migration
   - *m* la version d'arrivée
 
-- respecter une convention de nommage de la forme
-  MigrationClass où:
+- respecter une convention de nommage de la forme ``MigrationClass`` où:
 
   - *Class* est le nom de l'entité devant être migrée
 
-  Exemple, pour migrer une Personne d'une version 2 à 2.1:
-  ``V2V2_1.MigratePersonne.java``
+  Exemple, pour migrer une *Personne* d'une version 2 à 2.1 le nom de la classe
+  sera : ``V2V2_1.MigratePersonne.java``
 
   Note: les "." étant interdits dans le nom de fichier, ils sont remplacés par
   le caractère "_".
@@ -152,9 +156,10 @@
 
 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 :
+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 :
 
 ::
 
@@ -188,3 +193,13 @@
   ``domaine.Personne``
 - implémente ``migrate()`` pour produire des tuples de type ``domaine.Naissance``
   à partir de tuples ``domaine.Personne``
+
+Création de schéma
+~~~~~~~~~~~~~~~~~~
+Dans le cas où l'application est ammenée à créer un schéma de base de données,
+elle doit en informer le module de migration pour que celui-ci renseigne
+la version du schéma créé.
+
+Le module s'enregistre automatiquement aupres de ToPIA pour savoir quand
+celui-ci a créé un nouveau schéma. Il renseigne donc automatiquement la version
+par la suite.
\ No newline at end of file