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 :

testcase: testFindLike(info.touret.mycellar.test.BottleTest):        Caused an ERROR
Problem with query <SELECT A FROM info.touret.winecellar.pojo.Bottle A WHERE A.name like 'BOUTEILLE%'  or A.vintage like '2001%'>: Or filters cannot be applied to multiple properties (found both name and vintage).
org.datanucleus.store.appengine.query.DatastoreQuery$UnsupportedDatastoreFeatureException: Problem with query <SELECT A FROM info.touret.winecellar.pojo.Bottle A WHERE A.name like 'BOUTEILLE%'  or A.vintage like '2001%'>: Or filters cannot be applied to multiple properties (found both name and vintage).
        at org.datanucleus.store.appengine.query.DatastoreQuery.addLeftPrimaryOrExpression(DatastoreQuery.java:1131)
        at org.datanucleus.store.appengine.query.DatastoreQuery.addLeftPrimaryExpression(DatastoreQuery.java:1105)
        at org.datanucleus.store.appengine.query.DatastoreQuery.addPrefix(DatastoreQuery.java:931)
        at org.datanucleus.store.appengine.query.DatastoreQuery.handleMatchesOperation(DatastoreQuery.java:891)
        at org.datanucleus.store.appengine.query.DatastoreQuery.addExpression(DatastoreQuery.java:864)
        at org.datanucleus.store.appengine.query.DatastoreQuery.addExpression(DatastoreQuery.java:835)

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

@OneToOne(cascade = {CascadeType.REFRESH})
    private Key producer;

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

@OneToOne(cascade = {CascadeType.REFRESH})
    @Column(name = "producer", insertable = false, updatable = false)
    private Producer producerAlias;

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 :

Query query = em.createQuery("select from Bottle b join b.producerAlias");

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 ...

Qu'est ce qu'on se fait ch ... !