RE : JDO : suite...

Thu, 20 Mar 2003 22:55:47 -0800

Title: Message
Il est facile � tout un chacun de downloader un produit JDO tel que LiDO (www.libelis.com) et de v�rifier par soi m�me que ce qui est affirm� par Cedric est absolument faux.
 
De par leur complexit� de d�veloppement, leur difficult� de mont� en charge et leur limitation du point de vue objet (h�ritage, polymorphisme) les Entity Beans (m�me 2.0) sont � r�server � des composants � forte granularit�.
Une simple lecture des threads sur theServerSide montre ce que l'immense majorit� des d�veloppeurs pense de CMP 2. L'avis d'Olivier refl�te largement l'opinion g�n�rale, m�me s'il n'a apparemment pas test� CMP 2 r�cemment.
 
  • Pas d'equivalents de SELECT (oblige de faire plusieurs allers-retours vers la DB, pas possible de recuperer des objets partiellement)
Il ne faut pas confondre un standard avec les produits qui l'impl�mentent.
Tous les produits JDO s�rieux permettent de g�rer cela efficacement m�me si cela n'est pas impos� par le standard.
A noter de plus que dans LiDO le filtre d'une query peut �tre en JDOQL ou en SQL pur.
 
  • Pas de curseurs scrollables
M�me probl�me. Un produit comme LiDO supporte cela.
C'est effectivement un point important.
  • Pas d'outer joins
N'importe quoi !!!
  • Pas d'API precise pour le cache
Faux, il y a des APIs de cache dans JDO.
De plus, LiDO dispose de 4 niveaux de cache, y compris caches partag�s et caches distribu�s.
La configuration peut se faire par API ou de fa�on externe � l'application (properties).
  • Pas de cache incremental de relation ou batch
Faux.
  • Pas de verrouillage optimiste
Faux, JDO d�finit le comportement optimiste.
Et c'est justement un des points forts de LiDO qui dispose d'options tr�s sophistiqu�es pour le verrouillage optimiste.
Je n'ai jamais vu l'�quivalent dans d'autres produits de mapping.
 
 
Si tu as fait une croix sur EJB (ce qui est une erreur si tu n'as jamais experimente avec CMP 2.0, a mon avis), je recommande Hibernate plutot que JDO.
 
Hibernate n'est pas un mauvais produit.
Mais il est totalement propri�taire, pas outill� du tout (ils communiquent l�-dessus), bas� sur de la runtime-reflection et loin d'�tre aussi sophistiqu� que LiDO sur bien des points (locking optimiste par exemple).
Mais surtout, il est bien moins performant, ce qui est souvent un crit�re fondamental.
 
Donc moi, je recommande aux gens de se faire une id�e par eux-m�mes en comparant les technologies.
Cdt,
______________________
Eric Samson, LIBeLIS
Enterprise Information Access
www.libelis.com
-----Message d'origine-----
De : Cedric Beust [mailto:[EMAIL PROTECTED]
Envoy� : vendredi 21 mars 2003 03:45
� : [EMAIL PROTECTED]
Objet : Re: JDO : suite...

Olivier Richaud wrote:
A l'�poque, on avait regard� les entity beans des EJB pour r�aliser la
persistence, mais nous nous sommes tr�s tr�s vite rendu compte que ce
n'�tait strictement pas exploitable, ni en terme de performance, ni en terme
de navigation. Au final, le design conduisait � �crire beaucoup de code avec
JDBC dans les m�thodes ejbLoad, ejbStore.
Donc tu as teste uniquement BMP ?  Et jamais CMP 2.0 ?
2- Le langage pour faire les queries n'est ni OQL, ni SQL. Avez-vous d�j�
constat� de graves lacunes? Peut-on aujourd'hui faire ce que nous avons
r�ussi � faire avec SQL?
  • Pas d'equivalents de SELECT (oblige de faire plusieurs allers-retours vers la DB, pas possible de recuperer des objets partiellement)
  • Pas de curseurs scrollables
  • Pas d'outer joins
  • Pas d'API precise pour le cache
  • Pas de cache incremental de relation ou batch
  • Pas de verrouillage optimiste
Si tu as fait une croix sur EJB (ce qui est une erreur si tu n'as jamais experimente avec CMP 2.0, a mon avis), je recommande Hibernate plutot que JDO.

-- 
C�dric

Répondre à