...
Ce fichier est dans le répertoire META-INF du module pour pouvoir être utilisé par différents autres modules. Typiquement la couche web et la couche batch.
A noter que ce bean étend abstractDomainAwareBean ce qui veut dire qu'il a accès au DomainService (ce qui lui permet notamment de savoir en quelle version est la base de données). De fait, il étend aussi AbstractApplicationAwareBean ce veut dire qu'il a accès au ApplicationService (définit via example-domain-services-application.xml, ce qui lui permet de savoir en quelle version est l'application). VersionningService saura donc, entre autres choses, vérifier la cohérence entre la base de données et l'application.
Stockage de la version
La version de la base de données est stockée dans la base de données elle même. Pour manipuler cette version il y a du code métier, dao et un mapping objet/relationnel*.*
...
| Remarque |
|---|
La version hibernate utilisée comme implémentation de JPA ne semble pas bien supporter les fichiers de mapping XML au format standardisé par JPA. Aussi nous utilisons un fichier de mapping XML spécifique à hibernate. |
VersionManager.hbm.xml dans le répertoire META-INF de example-dao :
| Bloc de code | ||
|---|---|---|
| ||
<hibernate-mapping package="org.esupportail.example.domain.beans">
<class name="VersionManager">
<id name="id">
<generator class="native">
<param name="sequence">VersionManager_id</param>
</generator>
</id>
<property name="version" length="20" />
</class>
</hibernate-mapping> |
Note : Le fait le fichier hbm soit dans le classpath suffit
Code DAO
Dans la mesure où n'est stockée que la version courante a 3 méthodes : getVersionManager, addVersionManager et deleteVersionManager
Code métier
getDatabaseVersion qui permet de savoir en quelle version est la base de donnée
updateDatabaseVersion qui permet de supprimer la version astockée en base pour la remplacer par une nouvelle
Vérification de version
| Remarque |
|---|
Si l'application n'est pas en phase avec la version de la base de données alors on peut être amener à mettre à jour cette dernière. Cf. 3.3.3 Gestion de la structure de la base de données |
La vérification de cohérence entre la version de la base de données et la version de l'application est faite pour chaque appel à la couche métier pouvant avoir un impact sur la base de données. Elle est faite via la méthode checkVersion du VersionningService. Cet appel est fait via APO et déclenchera une exception si l'application et la base de données ne sont pas en cohérence.
example-domain-services-domain.xml :
| Bloc de code | ||
|---|---|---|
| ||
<aop:config>
<aop:pointcut id="txMethods"
expression="within(org.esupportail.*.domain.DomainServiceImpl)
&& (execution(* add*(..)) || execution(* delete*(..)) || execution(* update*(..)))
&& !execution(* *DatabaseVersion(..))" />
<aop:aspect id="checkDbVersion" ref="versionningService">
<aop:before pointcut-ref="txMethods" method="checkVersion" />
</aop:aspect>
</aop:config>
|
A noter : Le point de coupe APO est un peu complexe. Il prend toutes les méthodes de la classe DomainServiceImpl qui commence par add*, delete* et update* (soit toutes les méthodes qui peuvent avoir un impact sur la base de données) mais exclu les méthodes *DatabaseVersion. En effet, ces dernières peuvent aussi interagir avec la base de données pour mettre à jour la version de la base de données. Il est important de les exclure de la vérification pour éviter une boucle infinie.example-domain-services/src/main/resources/META-INF/example-domain-services-application.xml