Nous avons commencé en début de semaine le développement de ToPIA 3. Le but est de se baser sur JPA 2 plutôt que directement sur Hibernate. Ceci devrait nous permettre à terme d'être indépendant de l'implémentation de JPA 2 et donc de pouvoir utiliser autre chose qu'Hibernate. Voici un peu ce que nous avons fait cette semaine. Le module topia-persistence ne dépend plus d'Hibernate, mais dépend de l'API JPA (en provided car chaque implem vient avec son API - pratique !). On ne parle plus de Session Hibernate, mais d'EntityManager. La création d'un EntityManagerFactory passe par une méthode statique (fournie par l'API JPA) qui va chercher dans le classpath un fichier indiquant quel PersistenceProvider il faut utiliser. Le module topia-persistence contient un PersistenceProvider abstrait qui uniformise le comportement quel que soit l'implémentation JPA. Un nouveau module a été créé (topia-persistence-hibernate) qui dépend de topia-persistence et Hibernate (dernière version) et qui fournit un PersistenceProvider en n'implémentant que la partie spécifique à la création d'un EntityManagerFactory Hibernate. Ce PersistenceProvider permet de lire à la fois des fichiers de mapping MonEntite.hbm.xml et MonEntite-orm.xml. Il reste malgré tout un certain nombre de choses qui étaient dans topia-persistence mais qui sont spécifiques à l'implémentation de JPA : - la gestion du schéma (SchemaExport, SchemaUpdate) ; - l'import/export XML ; - la réplication d'entités ; - ... (certainement d'autres qu'on a pas encore bien identifié) Pour gérer ces cas particuliers, j'ai créé une interface (TopiaSpecificUtil - oui je sais le nom est moisi, mais j'ai pas mieux) qui regroupe les méthodes que le TopiaContext ne peut accomplir sans une implémentation spécifique. Lors de la création du PersistenceProvider de l'implémentation choisie, une instance spécifique est créée et injectée au TopiaContext qui pourra ensuite l'utiliser pour les méthodes non JPA. (NB: La gestion du schéma a été migrée dans le module hibernate, mais pas encore l'import/export XML et la réplication d'entités) Le module topia-persistence fournissait aussi un ConnectionProvider qui corrige celui de base d'Hibernate. Étant donné que c'est spécifique Hibernate, ça a été tout naturellement déplacé dans le module topia-persistence-hibernate. Au niveau de la génération des mappings XML, Tony s'arrache bien les cheveux : beaucoup de choses que nous définissions auparavant dans la génération des .hbm.xml n'existe pour les mappings -orm.xml. Nous ne savons pas encore si ces limitations vont être bloquantes. Pour rajouter un peu de peine à la réécriture du générateur, la XSD impose un ordre entre les informations d'une entité (tous les one-to-one, PUIS tous les one-to-many PUIS ... - pratique !). D'autre part, comme 90% des gens utilisent les annotations, 90% des docs qu'on trouve ne parlent même pas des mappings XML : pratique ! (Tony je te laisse compléter si tu veux) Comme nous avons rendu topia-persistence indépendant d'une implémentation JPA, les tests présents dans ce module et nécessitant Hibernate ne peuvent plus s'exécuter depuis ce module (dépendance cyclique). Nous avons donc créé un module topia-persistence-tck (pour Test Compatibility Kit) qui dépend de topia-persistence et qui contient des tests en src/test (non dépendant d'une implem) et des TestSuite en src/main. Dans le module topia-persistence-hibernate, nous avons une dépendance en scope test vers le module topia-persistence-tck et nous surchargeons les TestSuite, ce qui fait que les mêmes tests pourront être partagés entre les différents modules topia-persistence-(hibernate|openjpa|...) À l'heure actuelle, une grande majorité des tests passent en utilisant les mappings .hbm.xml, nous ne savons pas encore ce que ça donnera avec les mappings -orm.xml. Personnellement, je pense que ça va le faire (naturellement optimiste ?) je suis ""juste"" inquiet sur la propagation des évènements (je vais faire un mail dédié). Tony est moins confiant, c'est surement dû au fait que c'est lui qui s'occupe des mappings ORM... Arnaud
On Fri, 11 May 2012 18:42:20 +0200 Arnaud Thimel <thimel@codelutin.com> wrote:
Un nouveau module a été créé (topia-persistence-hibernate) qui dépend de topia-persistence et Hibernate (dernière version) et qui fournit un PersistenceProvider en n'implémentant que la partie spécifique à la création d'un EntityManagerFactory Hibernate. Ce PersistenceProvider permet de lire à la fois des fichiers de mapping MonEntite.hbm.xml et MonEntite-orm.xml.
Il faudrait qu'on rediscute des noms des paquetages car je suis pas trop fan de rajouter un paquetage hibernate dans un module dédié à hibernate et avec Hibernate rajouté en plus dans chaque classe. Je serais plus pour supprimer les paquetages *hibernate* qui n'apporte rien, je trouve bien que les implémentations soient dans le paquet d'implantation.
Il reste malgré tout un certain nombre de choses qui étaient dans topia-persistence mais qui sont spécifiques à l'implémentation de JPA : - la gestion du schéma (SchemaExport, SchemaUpdate) ; - l'import/export XML ; - la réplication d'entités ; - ... (certainement d'autres qu'on a pas encore bien identifié)
Pour gérer ces cas particuliers, j'ai créé une interface (TopiaSpecificUtil - oui je sais le nom est moisi, mais j'ai pas mieux) oui faut trouver quelquechose de mieux car là c'est trop bateau :(
Cela concerne de la persistence donc je pense qu'on devrait mettre persistence dedans. J'aime pas du tout le *Specific*.
qui regroupe les méthodes que le TopiaContext ne peut accomplir sans une implémentation spécifique. Lors de la création du PersistenceProvider de l'implémentation choisie, une instance spécifique est créée et injectée au TopiaContext qui pourra ensuite l'utiliser pour les méthodes non JPA.
(NB: La gestion du schéma a été migrée dans le module hibernate, mais pas encore l'import/export XML et la réplication d'entités)
Le module topia-persistence fournissait aussi un ConnectionProvider qui corrige celui de base d'Hibernate. Étant donné que c'est spécifique Hibernate, ça a été tout naturellement déplacé dans le module topia-persistence-hibernate. Oui faudrait voir au niveau de openJPA ce qu'ils utilisent
Au niveau de la génération des mappings XML, Tony s'arrache bien les cheveux : beaucoup de choses que nous définissions auparavant dans la génération des .hbm.xml n'existe pour les mappings -orm.xml. Nous ne savons pas encore si ces limitations vont être bloquantes. Pour rajouter un peu de peine à la réécriture du générateur, la XSD impose un ordre entre les informations d'une entité (tous les one-to-one, PUIS tous les one-to-many PUIS ... - pratique !). D'autre part, comme 90% des gens utilisent les annotations, 90% des docs qu'on trouve ne parlent même pas des mappings XML : pratique !
(Tony je te laisse compléter si tu veux)
que dire de plus ? non c'est juste pas du tout documentée :(
Comme nous avons rendu topia-persistence indépendant d'une implémentation JPA, les tests présents dans ce module et nécessitant Hibernate ne peuvent plus s'exécuter depuis ce module (dépendance cyclique). Nous avons donc créé un module topia-persistence-tck (pour Test Compatibility Kit) qui dépend de topia-persistence et qui contient des tests en src/test (non dépendant d'une implem) et des TestSuite en src/main. Dans le module topia-persistence-hibernate, nous avons une dépendance en scope test vers le module topia-persistence-tck et nous surchargeons les TestSuite, ce qui fait que les mêmes tests pourront être partagés entre les différents modules topia-persistence-(hibernate|openjpa|...)
Concernant les tests, on a éclaté le modèle de test pieuvrèsque... et 3 modèles : - legacy (veut tout dire... ancien fourtout qu'on va essayé de supprimer) - mapping (pour tester la migration des mappings hbm -> orm) - it (pour créer un vrai modèle métier de test de topia) On a donc 3 tests suites possibles.
À l'heure actuelle, une grande majorité des tests passent en utilisant les mappings .hbm.xml, nous ne savons pas encore ce que ça donnera avec les mappings -orm.xml.
Personnellement, je pense que ça va le faire (naturellement optimiste ?) je suis ""juste"" inquiet sur la propagation des évènements (je vais faire un mail dédié). Tony est moins confiant, c'est surement dû au fait que c'est lui qui s'occupe des mappings ORM... C'est vrai que j'ai bien galéré (et c'est pas fini :() je pense avoir fini demain. Mais je pourrais peut-être pas tout commité.
J'essaye de t'apeller Arnaud qu'on revoit tout ça ensemble, histoire de dire que tu as conçu toi même tout le ToPIA-3 :(, :). En tout cas on a bien avancé et c'est quand même encourageant. Bravo Arnaud \o/ (et moi !) -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 13/05/2012 19:22, Tony Chemit a écrit :
On Fri, 11 May 2012 18:42:20 +0200 Arnaud Thimel <thimel@codelutin.com> wrote:
Un nouveau module a été créé (topia-persistence-hibernate) qui dépend de topia-persistence et Hibernate (dernière version) et qui fournit un PersistenceProvider en n'implémentant que la partie spécifique à la création d'un EntityManagerFactory Hibernate. Ce PersistenceProvider permet de lire à la fois des fichiers de mapping MonEntite.hbm.xml et MonEntite-orm.xml.
Il faudrait qu'on rediscute des noms des paquetages car je suis pas trop fan de rajouter un paquetage hibernate dans un module dédié à hibernate et avec Hibernate rajouté en plus dans chaque classe.
Je serais plus pour supprimer les paquetages *hibernate* qui n'apporte rien, je trouve bien que les implémentations soient dans le paquet d'implantation.
Oui, pareil en fait. Je ne savais pas trop comment allait évoluer le module, mais ça a l'air de se stabiliser comme ça, donc j'applique dans le prochain commit.
Il reste malgré tout un certain nombre de choses qui étaient dans topia-persistence mais qui sont spécifiques à l'implémentation de JPA : - la gestion du schéma (SchemaExport, SchemaUpdate) ; - l'import/export XML ; - la réplication d'entités ; - ... (certainement d'autres qu'on a pas encore bien identifié)
Pour gérer ces cas particuliers, j'ai créé une interface (TopiaSpecificUtil - oui je sais le nom est moisi, mais j'ai pas mieux) oui faut trouver quelquechose de mieux car là c'est trop bateau :(
Cela concerne de la persistence donc je pense qu'on devrait mettre persistence dedans.
J'aime pas du tout le *Specific*.
Bah ouais, mais pour exprimer le fait que c'est spécifique à l'implem de JPA, j'ai pas encore trouvé mieux. TopiaJPADependantPersistenceUtil ? :( Arnaud
Le 14/05/2012 12:04, Arnaud Thimel a écrit :
Il reste malgré tout un certain nombre de choses qui étaient dans topia-persistence mais qui sont spécifiques à l'implémentation de JPA : - la gestion du schéma (SchemaExport, SchemaUpdate) ; - l'import/export XML ; - la réplication d'entités ; - ... (certainement d'autres qu'on a pas encore bien identifié)
Pour gérer ces cas particuliers, j'ai créé une interface (TopiaSpecificUtil - oui je sais le nom est moisi, mais j'ai pas mieux) oui faut trouver quelquechose de mieux car là c'est trop bateau :(
Cela concerne de la persistence donc je pense qu'on devrait mettre persistence dedans.
J'aime pas du tout le *Specific*. Bah ouais, mais pour exprimer le fait que c'est spécifique à l'implem de JPA, j'ai pas encore trouvé mieux.
TopiaJPADependantPersistenceUtil ? :(
TopiaDialect ? Arnaud
Le 11/05/2012 18:42, Arnaud Thimel a écrit :
Voici un peu ce que nous avons fait cette semaine.
Update semaine 20 : Amélioration du chargement de la configuration JPA : Reprise des subtilités de ToPIA 2. Implémentation des events sur Hibernate uniquement. Ça semble compromis en pur JPA. D'une part on est pas sur du pur JPA, d'autre part on a besoin que l'entité contienne le TopiaContext, donc bof bof bof. (cf thread dédié) Retrait des messages d'exception i18n. Implémentation du "replicate" sur Hibernate. Tony a bien avancé sur la génération des mappings et a ajouté la possibilité d'utiliser les mappings HBM ou ORM en fonction de la conf. Il y a maintenant un fichier TopiaEntityAbstract-orm.xml qui déclare une mapped-superclass avec les topiaId|Version|... Nous avons donc pu faire les premiers tests avec les mappings ORM et ... c'est pas beau à voir :( En effet, comme on génère le topiaId, Hibernate pense que c'est une entité détachée (existante mais non liée à une session), or Hibernate refuse qu'on fasse un persist sur un objet détaché : "detached entity passed to persist: org.nuiton.topia.tck.legacy.entities.PersonImpl" Tony a réussit à contourner le soucis en mettant la génération du topiaId dans un EventListener prePersist. À priori ça fonctionne, mais seulement avec les mappings ORM. En soit, ça n'est pas déconnant, faut voir si c'est pérenne... Arnaud
participants (2)
-
Arnaud Thimel -
Tony Chemit