Blog#9

Comme tout bon geek qui se respecte, voila deux semaines que je joue avec le Google App Engine.
Mon idée de base était simple : dans quelle mesure une application existante peut-elle être portée dans les nuages de GAE ?
Etant modeste et fainéant, j'ai tenté d'adapter l'application de démonstration Gilead, basée sur Hibernate.

L'application en elle-même est très simple (je venais de la simplifier lors du portage à GWT 1.6) : un utilisateur est associé à un ou plusieurs messages, l'IHM permettant d'interroger et de mettre à jour la base, le tout basée sur une simple association un-à-plusieurs. GAE n'aime pas Hibernate ! Comme vous l'avez sans doute lu un peu partout, Google App Engine est basé sur DataNucleus, une librarie de persistance JDO. Ce choix technologique surprenant (qui se justifie sans doute au niveau de l'infrastructure mise en œuvre par Google) me laisse perplexe : il semble évident que JDO est en perte de vitesse et a clairement perdu la bataille ORM contre Hibernate et JPA. Que ce soit pour de bonnes ou de mauvaises raisons est un autre débat, mais clairement, le marché a tranché en faveur de JPA. Et justement, l'argument massue est que DataNucleus fournit aussi une surcouche JPA. Massue, vous avez dit?... Voyons voir ça ! JPA-dry Me voila donc avec mes entités JPA marchant parfaitement avec Hibernate. Qu'en est-il avec DataNucleus?.. Première difficulté : la gestion des ID. Sur ce point, DataNucleus est assez tatillon : * Pas de support de la stratégie d'ID "AUTO", passage obligatoire en "IDENTITY" * Pas de support des ID entiers (Integer) : d'après cette page, seules les clés Long, String ou Key sont acceptées... * Idem pour mon champs "Version" (passage en Long obligatoire) Pour les reste du mapping, c'est à peine plus simple, notamment concernant les associations. En convertissant l'ID en Long, j'ai eu le droit au message suivant : Error in meta-data for net.sf.gilead.sample.domain.Message.id: Cannot have a java.lang.Long primary key and be a child object (owning field is net.sf.gilead.sample.domain.User.messageList) D'après la doc, les clés entières ne peuvent être utilisées que pour les entités sans associations, sinon il faut utiliser une instance de la classe Key, ou une String encodée. Ayant pour but de faire fonctionner mon application avec GWT, j'opte donc pour la seconde solution : @Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@Column(name="ID")
@Extension(vendorName="datanucleus", key="gae.encoded-pk", value="true")
private String id; Dernière petite tracasserie, j'ai eu le malheur de renseigner l'entity-name de ma classe (@Entity(name="Message")), ce qui génère des erreurs aux messages peu explicites... Ouf, mon mapping est enfin terminé. Avouez que l'on est loin de l'objectif de JPA, un standard portable sur toutes les implémentations ! EJBQL, lui aussi loin du compte... Première info : il faut passer le nom complet de la classe dans vos requête, sinon DataNucleus soulève une ClassNotResolvedException : "select user from net.sf.gilead.sample.domain.User user where user.login=:login" De même, la clause 'select' est obligatoire (comme quoi, je doit être intoxiqué par Hibernate :>>) Par contre, comme indiqué dans la doc, il faudra apprendre à se passer des jointures. Ouch ! Moi qui avait pour habitude de définir mes chargement par ce biais, je suis bon pour charger explicitement mes associations une à une en appelant les getters qui vont bien. Conclusion Autant l'avouer, je suis un peu refroidi par le support JPA fourni par Google App Engine. L'implémentation retenue manque de souplesse, et s'avère relativement contraignante à mettre en oeuvre. A ce point, il me semble inenvisageable de porter une application JPA existante sous Google App Engine sans un gros travail. Par contre, une fois connue la bonne méthode, utiliser JPA pour développer une nouvelle appli GAE me semble relativement pertinent (autant que de devoir apprendre JDO...) Note importante : Comme indiqué par Erik dans les commentaires, ces limites proviennent pour l'essentiel des limites du DataStore de GAE, et non de DataNucleus, dont le support JPA est bel et bien certifié. Et la suite... Pour autant, mon périple n'est pas fini. Si j'ai à peu près réussi à dompter DataNucleus, il reste un problème de taille : l'envoi des entités JPA/DataNucleus vers GWT echoue systématiquement avec le message suivant : Type '[Ljava.lang.Object;' was not included in the set of types which can be serialized by this SerializationPolicy or its Class object could not be loaded. For security purposes, this type will not be serialized.
Problème de sérialisation GWT et de classes "enrichies" (enhanced), autant dire le syndrome Hibernate4GWT B) Je suis assez surpris que ce point n'aie jamais été testé par les équipes GAE et/ou GWT, et je travaille pour l'instant avec l'un des auteur de DataNucleus pour voir comment contourner ce problème. Stay tuned !