Pour ceux qui peuvent venir sur Paris, LIBeLIS organise un s�minaire mensuel gratuit sur JDO et LiDO. Toutes ces questions y sont largement abord�es en d�tail. La prochaine session est jeudi matin prochain (le 27), c'est � Paris (voir sur www.libelis.com). (en plus d'un bon caf� on a aussi le droit � des croissants de chez Poilane :-)
Mais bri�vement : Evidemment LiDO permet d'acc�der � des sch�mas de bases existants. JDOQL est un langage de query simple, � destinataion des programmeurs, dont le but est de trouver efficacement des objets � partir desquels naviguer ensuite en pur Java. Il n'a pas vocation � remplacer JDBC (analyse de donn�es, reporting, etc.). Donc JDOQL : * � une syntaxe � la fois d�clarative (comme un statement SQL) * et � la fois Java compliant (le filtre est une expression Java bool�enne) * JDOQL est portable executable sur toute source de donn�es (SGBDR, SGBDO, fichiers plats...) * JDOQL supporte l'h�ritage * JDOQL supporte la naviagtion � travers les r�f�rences Java et les collections * JDOQL supporte les order by, simples ou complexes Mais : * JDOQL ne supporte pas les union, having, group by et autres, ce n'est pas le but. En plus de ��, LiDO supporte des filtres exprim�s en SQL, et permet d'appeler les Stored Procs. NB: LiDO supporte les SGBDR, mais aussi le SGBDO Versant et est livr� avec sa propre base de donn�es l�g�re pour le monde embarqu� FileDB. Hope this helps... Cordialement, ______________________ Eric Samson, LIBeLIS Enterprise Information Access www.libelis.com -----Message d'origine----- De : Patrice Godard [mailto:[EMAIL PROTECTED] Envoy� : jeudi 20 mars 2003 10:25 � : [EMAIL PROTECTED] Objet : Re: JDO : suite... Je devrais me pencher sur la m�me probl�matique � partir de la semaine prochaine. J'ai exactement le m�me soucis (framework maison non satisfaisant et n�cessit� de mapper sur des tables, et dans mon cas des proc�dures PL/SQL existantes). Il me semble avoir lu quelque chose l�-dessus dans la doc de LIDO que je n'ai fait que survoler. more on this later... -----Original Message----- From: "Olivier Richaud" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Thu, 20 Mar 2003 09:59:11 +0100 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. -- S'il n'y a pas de solution, il n'y a pas de probl�me --
