Write once , run everywhere … sauf sur google app engine

Après la mise à jour des différents composants ( GAE #1.3.5 , primefaces 2.1RC1, …) me voila reparti à re-développer une appli sur GAE. Après quelques galères tests unitaires, j’ai pu me rendre compte des nombreuses limitations à JPA / GAE.

Les requêtes

D’abord, seul JPA V1 est implémenté. Ça a l’air con comme ca, mais par exemple on ne peut pas utiliser les CriteriaQuery alors que l’API JDO fournie par Google fournit les Filter.Après , me direz vous, c’est pas l’extase, ca ne fait pas exactement la même chose, on peut coder directement les critères en JPQL. Mais voila dès que vous voulez faire des recherches un peu larges avec par exemple un formulaire de recherche à critères multiples, vous pouvez obtenir l’erreur suivante :

Un peu bête …

Les jointures et fetching

Sur ce sujet, je me suis arraché les cheveux pas mal de temps. Exemple : ne Jointure OneToMany ne me ramenait pas du tout les entités en question lors d’un select. Que faire ?? Après quelques recherches sur la toile, je me suis rendu à l’évidence, que GAE ne gérait que les jointures via les clés primaires. Oubliez les belles jointures bi directionnelles et uni directionnelles JPA . L’insertion , la modification ne peut s’effectuer que par les clés primaires

Exemple avec une relation onetoone

Mais il est possible de « hacker » la matrice en rajoutant un autre attribut à notre classe qui aurait la configuration suivante :

Donc pour les insertions, suppressions, nous sommes obligés de passer par l’instance de la classe Key, par contre, une sélection passerait par l’alias. Cette manipulation permet de gérer la jointure ( avec fetch !) directement au niveau de la requête JPQL.

Exemple :

C’est un peu biaisé, mais bon ca simplifie la vie au niveau des requêtes.

Après, ce n’est que mon avis, je me suis trouvé pas mal obligé de dé-normaliser mes relations entre entités. Par exemple, je me suis mis dans l’idée de faire un nuage de tags. Bien au lieu de créer un pojo tag qui serai persisté directement dans big table, j’ai préféré créer un attribut tagline pour mon entité maître. Ca m’a pris moins de temps à créer. après va falloir que j’optimise les requêtes par une gestion de cache par exemple.

Conclusion :

Quand on développe sur GAE, il faut à mon avis bien penser aux contraintes de cette plateforme, surtout sur la persistance des données. Le développeur JAVAEE habitué à hibernate/jpa peut vite pédaler dans la choucroute au début. A mon avis ( et pas que ) JDO est à préférer. l’API semble connaître moins de limites.

Pas mal de plaintes on été faite à ce sujet. Je viens de voir un article sur une recherche full text. A voir …

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *