Reprise du message précédent :
ouais
euh
ok
(select blablablabla->ben j'esperais plus avoir ça moi )

la base de donnée objet la plus connue c'est Versant non? ben y'a pas la gestion des transactions si?
de toute facon JDO, derrière tu peux mettre n'importe quel type de stackage, un RDBMS, un ODBMS, du xml, ce que tu veux, les specs ne limitent pas, et c'est un des buts de JDO, la portabilité niveau système de stockage. C'est même super facile de changer une fois ton application développée, grâce à la notion de "transparence" qu'apporte JDO, le développeur et l'objet métier n'a pas à connaitre le type de stockage  
le bonheur quoi

Non, elle existe toujours, mais elle a subi plusieurs rachats successifs. Et la grosse boite que ça a donné s'est retrouvé avec ce business négligeable (par rapport à son chiffre d'affaires), et elle a décidé d'arrêter le produit.
 
A ma connaissance, pour les anciens clients, il y a une petite boite française qui a l'autorisation de continuer la maintenance, mais pour des problèmes stupides de droits de propriétés, elle ne peut (si elle le souhaitait) ni reprendre le développement du produit, ni même le diffuser sous GPL.

_guigui_ a écrit a écrit : la base de donnée objet la plus connue c'est Versant non? ben y'a pas la gestion des transactions si? de toute facon JDO, derrière tu peux mettre n'importe quel type de stackage, un RDBMS, un ODBMS, du xml, ce que tu veux, les specs ne limitent pas, et c'est un des buts de JDO, la portabilité niveau système de stockage. C'est même super facile de changer une fois ton application développée, grâce à la notion de "transparence" qu'apporte JDO, le développeur et l'objet métier n'a pas à connaitre le type de stockage   le bonheur quoi

Versant était le concurrent le plus direct d'O2, et les produits étaient assez proches du point de vue fonctionnalités et performance. O2 ayant été arrêté il y a environ 3 ans, il est logique que Versant ait repris ses parts de marché en Europe (O2 y était leader loin devant Versant à l'époque).
 
Maintenant, la portabilité du stockage, c'est bien, mais à moins d'utiliser tous les SGBD sous-jacents comme de simples systèmes de fichiers transactionnels, la performance en prend un méchant coup. L'idée est certes belle mais pour avoir bossé sur le mapping objet-relationnel, je sais très bien comment se comporte le relationnel en pareil cas. Le même programme source devient 10 à 20 fois plus lent...
Et c'est parfaitement logique. Les modèles relationnel et objet  sont 2 modèles très différents : en gros dans le mappint objet-relationnel, on essaie de faire rentrer un modèle naturellement hiérarchique dans un modèle ensembliste plat...

est ce que l'un de vous a déjà une opinion sur le couplage EJB-JDO.
Je me pose  notament la question de savoir si les EJB entity et JDO font doublons, ou si ils se complètent.
 
quelqu'un a eu une expérience de ce type ?

Moi, j'ai lu un article une fois sur le couplage EJB-SGBDO (désolé en l'occurrence, il s'agissait de Versant).
Le résultat était 8 fois plus rapide que toutes les autres offres testées (les principales du marché). Les testeurs avaient fait ça, à l'origine à la marge de leur benchmark, et ils avaient été les premiers surpris...
 
Mais si vous voulez mon avis personnel, quand j'ai lu le papier, moi je n'ai pas été surpris...
 
greg> Tu semblais méfiant avant mon petit laïus avec le bout de code Java. Je serais très curieux de savoir d'où vient cette méfiance...

ben ce qui me gene c'est qu'il y a toujours un truc qui ressemble à une requete sql

Comment ça... ??  
 
Forcément, qu'on a des requêtes : les requêtes, c'est ce qu'on a trouvé de mieux pour récupérer un ensemble de données qui suivent des critères particuliers. On pourrait faire ça avec des itérateurs, évidemment, mais dès que tu as des index, le moteur de requêtes récupère les données beaucoup plus rapidement que par un simple itérateur (ou un curseur, si tu préfères)...
Et c'est vrai pour tous les types de SGBD.
Maintenant, que ça ressemble à SQL, c'est assez logique. Java ressemble à C++ du point de vue syntaxique, ce n'est pas pour cela qu'ils sont identiques.
L'avantage avec les SGBD objet, c'est que tu récupères directement des objets de ton langage (que tu utilises C++, Java, etc), sans mapping aucun.
 
Ce que j'ai montré au dessus, c'est de l'OQL : Object Query Language. La principale différence que je vois avec SQL, c'est qu'il est entièrement fonctionnel, et typé. Exemple : la fonction MAX attend une collection de numériques en argument, et renvoie un numérique du même type. Donc on peut écrire "max(select p.age from p in People)" (et non "select max(p.age) ..." comme en SQL).
 
Tu remarqueras aussi que dans la requête ci-dessus, j'ai appelé une méthode comme si j'avais accédé à un attribut... Autre avantage des SGBDO : on peut mettre à la poubelle la notion de procédure stockée ; la possibilité d'appeler des fonctions sur les objets est native dans le SGBD ! Et en plus, on n'écrit pas ça dans un pseudo-langage de script, mais dans le langage de programmation objet usuel.

bon j'ai pas tout suivi hein
ce qui me parraissait louche c'est que dans la requete j'ai cru voir que tu specifiais les attributs que tu voulais recuperer ... or ben moi je m'attendrais plutot a betement recuperer l'objet, point à la ligne.
pour ce qui est de la requete, ben oui, mais je preferais que ça soit une methode d'un objet qui me permette de recuperer tel ou tel type d'objet plutot qu'un String quoua...

ben là c'est parce que c'était les attributs qui l'interessaient. Si je ne me trompe pas, si tu ne spécifie pas l'attribut, c'est l'objet entier qui sera récupéré.

Bien sûr :
    select p from p in People
ou bien :
    select * from People

ha ok

 
officiellement, les EJB Entity et JDO ne sont pas en concurrence.
en effet, JDO ne bénéficie pas de la sécurité, de la gestion transactionnelle dont bénéficient les EJB.
 
par contre, Session Bean + JDO, alors là oui ca rentre en concurrence avec les Entity Beans... La différence se fait au niveau temps et de développement ET performances.
 
J'ai développé une appli une fois avec les Entity Beans CMP, une fois avec Session Bean + JDO, ben avec un modèle objet tout con (2  objets métier 1 relation 1-1) +100% en lecture pour JDO.
Bon aprés tout dépend de l'implémentation JDO utilisée, mais les premiers retours d'expérience sont excellents (plus le modèle est compliqué plus les Entity Beans prennent cher )!
 
D'ailleurs, la 1ère équipe chez Sun a avoir travaillé sur les specs 1.0 de JDO (dont le spec leader), a été réaffectée au développement de la nouvelle version de EJB CMP, où le mapping objet/relationnel sera à base de JDO  

_guigui_ a écrit a écrit :   D'ailleurs, la 1ère équipe chez Sun a avoir travaillé sur les specs 1.0 de JDO (dont le spec leader), a été réaffectée au développement de la nouvelle version de EJB CMP, où le mapping objet/relationnel sera à base de JDO

 
Ils vbont encore changer ça ?  
 
J'ai ai marre de toujours recoder la même chose  

bah vu le peu de succés des Entity Beans, ils ont intéret à plancher sur une nouvelle version chez SUN

_guigui_ a écrit a écrit : bah vu le peu de succés des Entity Beans, ils ont intéret à plancher sur une nouvelle version chez SUN

c'est clair !!
les entitybeans ca sux !

 
quand même! Quelle merde ce truc

alors?