[JDO] [Conseil]Quelle Implémentation ?

Version imprimable

26/01/2005, 13h04
hamed

[JDO] [Conseil]Quelle Implémentation ?

Bonjour,
je m'apprete a faire du mapping relationnel - objet dans le cadre d'un projet de moyenne envergure.
Je souhaite utiliser JDO
Quelle est selon VOUS l'implementation la plus interressante (simplicite,portabilite sur diff SGBDR)?

HIBERNATE?
VERSANT?
LIDO?
autre?

mon projet contient une trentaine de table;
je doit pouvoir Basculer entre Sql2000 server,MySql, PostGreSql .... au gré des decideurs ( j' ai basculé une appli dont la persistance etait gérée " a la main" avec du JDBC depuis SQL2000server vers MySql et je recommencerais pas....)

a cet instant j 'utilise MySql, mais attendu que cet outils ne gere pas l'integrité referentiel il se pourrait que dans quelques moi on me demande de passer sous PostGgre !

mrci a VOUS TOUS !
26/01/2005, 14h13
austin P.

Re: [JDO] [[CONSEIL]QUELLE IMPLEMENTATION ?

Citation:

Envoyé par hamed

Bonjour,
je m'apprete a faire du mapping relationnel - objet dans le cadre d'un projet de moyenne envergure.
Je souhaite utiliser JDO
Quelle est selon VOUS l'implementation la plus interressante (simplicite,portabilite sur diff SGBDR)?

HIBERNATE?

oublie ce n'est pas jdo (au meme titre que castor jdo d'ailleurs)

Citation:

Envoyé par hamed

VERSANT?
LIDO?
autre?

en fait tout dépend de ton besoin (update en masse, load massif, montée en charge,...) : définie les et test ces cas de figures.
je sais c'est con comme réponse mais le risque en posant cette question c'est que chacun te donne son avis sur le produit qu'il utilise sans comparaison possible. Là par exemple je peut te dire que j'ai apprécié Lido mais difficile de le comparer puisque c'est le seul que j'utilise.

Citation:

Envoyé par hamed

mon projet contient une trentaine de table;
je doit pouvoir Basculer entre Sql2000 server,MySql, PostGreSql .... au gré des decideurs ( j' ai basculé une appli dont la persistance etait gérée " a la main" avec du JDBC depuis SQL2000server vers MySql et je recommencerais pas....)

je compatie entièrement

Citation:

Envoyé par hamed

a cet instant j 'utilise MySql, mais attendu que cet outils ne gere pas l'integrité referentiel il se pourrait que dans quelques moi on me demande de passer sous PostGgre !

faux : mysql gère l'intégrité reférenciel

bon courage :wink:
26/01/2005, 17h02
bmoussaud

Rapidement:
Lido est une tres bonne implémentation stable et performante et Commerciale.
Du coté OpenSource est ouverture sur "ce que pourra etre JDO 2.0" regarde JPox !
26/01/2005, 18h47
hamed

hum ....HIBERNATE n'est pas une implemenation de JDO .... c'est quoi une variante de HIBERNATUS avec defunes?

et ... MySql gere l'integrite referentiel ??? je peux savoir quelle version??
26/01/2005, 19h18
austin P.

JDO n'est qu'une spécification : l'implemente qui veut
nb : hibernate est plus ancien que la norme JDO

concernant mysql cela fait un bon moment que c'est géré, comme les transactions...

et bientot les procédures stockées.

http://dev.mysql.com/doc/mysql/en/innodb-foreign-key-constraints.html

Citation:

Envoyé par la doc de mysql

Starting from MySQL 3.23.50, you can also associate the ON DELETE CASCADE or ON DELETE SET NULL clause with the foreign key constraint. Corresponding ON UPDATE options are available starting from 4.0.8. If ON DELETE CASCADE is specified, and a row in the parent table is deleted, InnoDB automatically deletes also all those rows in the child table whose foreign key values are equal to the referenced key value in the parent row. If ON DELETE SET NULL is specified, the child rows are automatically updated so that the columns in the foreign key are set to the SQL NULL value. SET DEFAULT is parsed but ignored.
27/01/2005, 08h00
bmoussaud

JDO n'est pas une norme mais une spécification :wink:
Concernant l'ancienneté hibernate / jdo je pense que jdo est plus agé, il porte quand meme le n°12 des JSR
http://jcp.org/aboutJava/communitypr...012/index.html
et EJB 3 porte le n° 220
27/01/2005, 10h54
austin P.

peut etre mais le final realease date du 30 avril 2002
http://www.jcp.org/en/jsr/detail?id=12

alors que le projet hibernate est de 2001
27/01/2005, 11h29
viena

Citation:

Je souhaite utiliser JDO

Pourquoi ? Y a t il des contraintes particulières qui t'y oblige? choix personnel ?

Hibernate tend à devenir incontournable dans le monde J2EE pour le mapping. Bien sur, je ne veux pas dire qu'il faut utiliser hibernate parce que tout le monde l'utilise. Mais de nombreux travaux, normalisations, associations... sont mis en place pour hibernate étant donnée son ampleur (CF EJB3).

Donc, si tu désire te former, il est peut être intéressant d'utiliser Hibernate.
27/01/2005, 12h06
bmoussaud

Citation:

Envoyé par austin P.

peut etre mais le final realease date du 30 avril 2002
http://www.jcp.org/en/jsr/detail?id=12

alors que le projet hibernate est de 2001

La spécification JDO a commencé tres tres tot ! environ vers le début 2000. J'ai d'ailleurs des versions notées 0.4 ayant la date de Octobre 2000. Par contre je suis d'accord avec toi la release 1.0 n'a abouti que vers le 30 avril 2002....et ceci je ne l'explique pas ... :?
27/01/2005, 13h32
hamed

Ecoutez merci de vos reponses , mon choix se penche vers HIBERNATE.Je le trouve plus saint comparer a d'autre implementation que je ne citerais pas ( avec enhancement de code, ,fichier XML alambiqué ...)

Pour repondre a VIENA je dirais que je veux utiliser JDO parce que :

- coder de façon redondante la meme logique d'acces a une base de données pour charger ou utiliser des objets metiers via JDBC ça prend du temps et ça apporte pas grand chose (intellectuellement )une fois qu'on a compris comment JDBC fonctionne.

- se retaper le meme codage avec les variantes SQL si on change de SGBDR ça devient franchement soulant

- parcourrir des centaines de lignes de codes pour ajouter ou suprrimer a un attribut d'un bean en fonction d'une modification du MCD ça me rend franchement nerveux

- les EJBS centité c 'est une plomberie monstre a mettre a place et aucune coherence entre conteneurs ( essaie d'implementer une relation 1-N avec les CMR tu te feras ton opinion ) et de plus mes projets n'ont pas de monté en charge colossale dans l'utilisation pour justifier la mise en place d'objets distribués.

donc JDO ça me semble adapté.
voila
27/01/2005, 14h08
viena

Je pense que tu confonds JDO et mapping.

Le mapping est ce que tu veux faire (et je comprend très bien tes raisons).

JDO est une spécification (comme le dit bmoussaud plus haut) concernant le mapping.

Hibernate n'est pas sur la norme JDO mais sur sa propre norme (qui va surement se généraliser, vu que c'est la norme choisi pour les EJB3).

Un petit tag résolu stp :wink: merci d'avance
27/01/2005, 16h44
fabriceMerc

Même si j'ai déja codé dans des applications J2EE multi-couche aucune n'utilisais le O/R mapping et actuellement pour un projet je m'interesse beaucoup à cette solution, seulement en lisant les tutos sur le site :

http://bmoussaud.developpez.com/tutoriel/java/jdo/

et

http://defaut.developpez.com/tutorie...pse/hibernate/

je n'arrive pas à discerner la différence/ressemblance entre JDO et hibernate :-( quelqu'un pourrait mieux eclairer le sujet ?
Et autre question dans le cas ou on a une base de donnés qui contient pas mal de procédures /triggers etc ... hibernate est-il vraiment utile ?
27/01/2005, 17h39
hamed

Pour repondre a frederiqueMerc je dirais :
JDO est une psecification permettant de faire du mapping "Relationnel / Objet"

Hibernate serait " une " implemenation de JDO (au mettre titre que Lido,Versant,Kodo etc ...) .....
mais il semblerait , si j'ai bien compris qu'Hibernate obeisse a sa propre specif car plus ancien que JDO ou qq chose comme ça ....donc Hibernate c'est "un moyen de faire du mapping relationnel - objet " semblable mais independante de JDO. enfin si j'ai compris ....
27/01/2005, 18h18
austin P.

Citation:

Envoyé par hamed

Pour repondre a frederiqueMerc je dirais :
JDO est une psecification permettant de faire du mapping "Relationnel / Objet"

Hibernate serait " une " implemenation de JDO (au mettre titre que Lido,Versant,Kodo etc ...) .....
mais il semblerait , si j'ai bien compris qu'Hibernate obeisse a sa propre specif car plus ancien que JDO ou qq chose comme ça ....donc Hibernate c'est "un moyen de faire du mapping relationnel - objet " semblable mais independante de JDO. enfin si j'ai compris ....

ouaip
comme on n'en a discuté plus haut avec bmoussaud, la spec JDO à commencé avant le projet hibernate mais la final release (la v1 quoi) n'est sortie seulement en 2002. A mon avis les gars d'hibernate en ont eut marre d'attendre :zzz: .

Mais au final le but pour JDO et Hibernate est le même : faire du mapping objet. A la petite différence c'est que JDO ne se limite pas au SGBDR.
31/01/2005, 18h32
ceddup

Toujours selon Rod Johnson et son merveilleux livre J2EE Development without EJB, p270, Gavin King le leader de Hibernate fait partie du groupe d'experts chargés de la spécification de JDO 2.0. JDO est une spécification large qui concerne le problème de la persistance des objets java sur tous types d'entrepôts de données (pas seulement les bases de données relationnelles). Cette spécification va contenir une partie appelée JDO/R qui concerne le mapping objet/relationnel. Hibernate étant le produit gratuit le plus aboutis à ce jour et étant utilisé par un très grand nombre de projets, il semble être un bon choix si l'on veut écrire avec des produits gratuits. Il rejoindra très probablement l'API JDO/R dès qu'elle sera définie. TopLink et LIDO (vrai JDO) sont de très bons produits commerciaux, qui ont fait leurs preuves, LIDO ayant l'avantage significatif d'être développé par une équipe française, si je ne m'abuse.
Voilà pour ce que j'en sais...

J'ai un blog!
02/02/2005, 15h07
manu2000b

[quote="austin P."]

Citation:

Envoyé par hamed

la spec JDO à commencé avant le projet hibernate mais la final release (la v1 quoi) n'est sortie seulement en 2002. A mon avis les gars d'hibernate en ont eut marre d'attendre :zzz: .

Hehe, ce n'est pas vraiment la raison principale.
02/02/2005, 15h11
manu2000b

Citation:

Envoyé par ceddup

Toujours selon Rod Johnson et son merveilleux livre J2EE Development without EJB, p270, Gavin King le leader de Hibernate fait partie du groupe d'experts chargés de la spécification de JDO 2.0. [...] Il rejoindra très probablement l'API JDO/R dès qu'elle sera définie. TopLink et LIDO (vrai JDO)

Gavin ne fait plus partie du group d'expertise JDO. Il est membre du groupe d'expertise EJB3.
Hibernate embrasse(ra) la partie mapping O/R de la spec EJB3.
Voir http://www.hibernate.org/About/RoadMap et http://annotations.hibernate.org

PS: Toplink n'implémente également pas la norme JDO
02/02/2005, 15h28
austin P.

Citation:

Envoyé par manu2000b

Hehe, ce n'est pas vraiment la raison principale.

allez emmanuel bernard :wink: toi qui fait partie du projet, dis nous pourquoi
02/02/2005, 16h35
manu2000b

Il ne connaissait que les EJB et JDBC ;-)
Plus sérieusement
Il existe quelques différences fondamentales entre l'approche JDO (1) et les approches prises par Hibernate et Toplink
Le fait de forcer une implémentation de fait dans la spec (implémenter PersistentCapable par bytecode enhancement - on peut le faire explicitement mais bon)
Une approche agnostique par rapport à la technologie de persistence (DB, XML etc) qui ne devrait pas faire perdre de vue qu'une base de donnée est derrière pour persister/récupérer les infos.
Des marketing features: l'équipe hibernate s'est toujours concentré sur les fonctionnalités concrètement utiles quitte à se mettre un certain nombre de gens à dos. Et on a vu des tableaux comparatifs relativement hallucinant venant de grands noms de JDO
Un modèle de requêtage mélangeant deux concepts : l'approche API et l'approche langage qui au final ne nous satisfait pas. Un bon système de requêtage devrait ressembler le plus possible au SQL ce que fait HQL, EJBQL)
La notion d'identités en JDO (surrogate, application, natural etc).
... Vous trouverez surement d'autres arguments dans les blogs d'hibernate, sur le forum voire même sur TSS :roll:
02/02/2005, 21h38
bmoussaud

Citation:

Envoyé par manu2000b

PS: Toplink n'implémente également pas la norme JDO

Non :nono: