R�ponse1 : Ayant la m�me probl�matique, je r�pond. Nous avions une application qui tournait sur Castor. Dont les r�sultats nous satisfaisaient pas. En effet, d�s que nous voulions remonter un objet, il nous monter toute une grappe d'objets impressionnant pour chaque jointure. Pour casser cel�, nous limitions les jointures dans le mapping en r�cup�rant les references et chargions l'objet si n�cessaire. ce qui est lourd et ce qui limite l'interet d'un mapping Objet relationnel. Pour les m�mes raisons, nous avions incorpor�s du pur JDBC dans notre couche de persistence. Maintenant nous sommes en train de passer � Toplink. Nous avons donc d�finis la politique suivante : On d�finit des interfaces dont l'impl�mentation castor/jdbc doit respecter quittent � d�grader les perfs, ces interfaces correspondent � l'impl�mentation Toplink voulue de notre couche de persistence. Toutes les couches au dessus de la persistence doivent dor�navant manipuler ces interfaces. Ainsi, le choix de l'impl�mentation se fait juste au moment de l'initialisation. Finalement, on "refactore" au fure et � mesure en . Ca � l'air de fonctionner, mais c'est laborieux.
R�ponse2 : Je pense que nous ne pouvons pas faire tout exactement ce que l'on peut faire avec SQL. Mais si le mapping est bon. On a des objets beacoup plus facilement manipulables que des tables. R�ponse3: Pour l'instant Toplink nous donne enti�re satisfaction et va nous permettre de d�finir r�ellement le mapping que l'on souhaite. Mais bon on a pas encore fait de tests de perf. Laurent. ----- Original Message ----- From: "Olivier Richaud" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 20, 2003 9:59 AM Subject: JDO : suite... > Bonjour � tous, > > Je regarde de plus en plus pr�s JDO pour remplacer du code �tablissant un > mapping Objet/Relationnel fait � la main. > > J'ai remarqu� que certains d'entre nous commencent � examiner cette techo. > > 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. > > > Nous avions aussi �valu� les bases de donn�es objets. > > D'o� notre propre mapping aujourd'hui que nous souhaiterions voir �voluer. > > Aujourd'hui, nous sommes pr�ts � �valuer JDO mais des questions restes en > suspend : > > 1- Comment reprendre le mapping sur les tables d�j� existantes et ne pas > partir "from scratch"? Je n'ai pas eu l'impression que cet aspect soit > beaucoup pris en compte par les implantations qui arrivent, alors que c'est > fondamental. > > 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? > > 3- Avez-vous une implantation � recommander? > > Merci � tous d'avance pour vos r�ponses. > > Olivier. > > >
