Aujourd'hui j'ai eu la chance d'aller assister, dans le locaux de Sun à Paris, à la présentation de la nouvelle norme JDO et à son implémentation LiDo réalisé par Libelis (www.libelis.com).
 
WHAAAAOUUUU!!! Ca déménage un max ce truc...
 
J'en avais bien sûr entendu parler sur différents portails, mais là après cette présentation j'ai vraiment compris l'ampleur de cette nouvelle norme.
 
Kelkun à déjà eu l'occasion de se pencher dessus (Benou, Dark, Very, cherry ou les autres)???
 
En tout cas moi je m'y met dès la semaine prochaine car justement je commence un nouveau projet en Jsp.

 
nan je connais pas. Tu pourrais faire un petit résumé ?

ca m'interesse aussi

moi aussi, je suis intéressé par un petit résumé

Houlà rude tâche que vous me demandez là... Bon jvais me lancer.
 
Actuellement un pb se pose au niveau du mapping objet relationnel en java.
 
En effet quand vous utilisiez une source de données comme un SGBD, avant l'apparition du JDO, plusieurs pbs se posaient comme la perdurabilité des données, leurs stockages, leurs conversions ou encore le grand nombres de requetes a faire vers le SGBD et le langage SQL peu adapté à la programmation objet. D'autres problèmes se posaient aussi comme la portabilité d'un code entre plusieurs SBGDR différents impossibles malgré JDBC (cela est plutôt normal car pleins de paramètres rentre en jeu comme le nombre de caractères dans les titres des colonnes, les keys... enfin bref toutes les différences entre MySQL et Oracle par exemple). Ne parlons même pas du pb de portabilité avec les SGBDO qui étaient encore pire. Cette approche était dite "Approche donnée"
 
JDO est plus qu'une nouvelle API, c'est carrément un nouveau concept qui vient de naître il y a maitenant 1 semaine avec l'"Approche objet". Plusieurs composants nouveaux apparaissent :
 
1/ Un nouveau langage de requête objet vient d'être crée, il s'agit du JDO-SQL. Les "bonnes vieilles" requêtes SQL disparaissent car elles étaient peu adapté à la programmation objet. Voici un ex de requête en JDO-SQL :
 
Query q = pm.newQuery(employe.class,"salaire>100000?" );
Collection emps = (Collection) q.execute();
 
(on recherche un employé (qui est ici un objet), donc le salaire soit supérieur à 100000 euros (string, contenu de la cellule du SGBDR par exemple))
 
Ce langage est universelle, vous pouvez l'appliquer à tous les SGBDR, SGBDO, fichiers binaires, fichier csv... et à toute source de données théorique (y'avait même un exemple dans lequel la source de données etaient un serveur SMTP...)
 
2/ Fini les transferts de requetes SQL à chaque INSERT, UPDATE... maitenant les données sont chargées (de façon complétement transparente pour le développeur) dans un super cache et toutes les modifications n'ont lieu que lorsqu'on le décide comme par exemple lors de la validation de la transaction. Une fois la source de données "mise" dans le cache, on peut naviguer comme on le veut dedans, on peut même utiliser si on le désire des notions de pointeurs par exemple. La gestion du cache est telle que l'on puisse charger des BDD colossales très simplement, la jvm se chargeant elle-même des la gestion mémoire/données. Tout cela de manière complétement transparente pour le développeur. Le but est que l'utilisateur final ne sache même plus sur quel SGDB tourne l'apps sur qu'il utilise. C'est une source de données, point.
 
En gros, maitenant avec JDO, quand on fait des prog utilisant des SGBD, on fait de la pure programmation java objet, on ne se prends plus du tout la tête sur les pbs BDD.
 
Il y a deux approches pour les projets :
 
A/ on utilise l'architecture JDBC pour l'améliorer
 
B/ on écrit tout en JDO avec des drivers spéciaux.
 
Gain de tps d'après SUN :  
 
30% au développement
50% à la maitenance
 
Et les perfs s'envolent grâce qu système de cache.
 
Une "bien" meilleure explication :
 
http://java.sun.com/products/jdbc/related.html#1

si ce truc marche, c la fin de bien des emmerdes ...

C'est une vrai requête? parce que si oui je comprend pas bien comment ca peut marcher : comment le système va comprendre que la comparaison porte sur la valeur de la chaine dont il faudra enlever la devise qui se trouve au bout ?

Heu je suis désolé je n'ai pas eu le tps de bien noter cette requête. En fait l'idée c'est :
 
Query q = pm.newQuery(un objet,un string);
 
L'objet est un objet classique java,
Le string représente la "condition".
 
Le gars de Sun a fait une démo avec une bdd contenant des employés et des infos diverses genres sociétés, salaire. Un truc très simple. Puis il a utiliser Poseidon et a partir du schéma UML, ce logiciel à créer toutes les classes. Il a rajouter quelques petites fonctions (genre créer un employé). puis il a fait tourner cet exemple en utilisant pour le stockage un SGBRD puis un SGBDO, puis une version simplifié dans un fichier binaire. Il nous a ensuite fait sa démo en utilisant Jsp/Servlets puis des EJB puis des Entity... (je sais pas ce que c'est désolé...)
 
Franchement j'ai bien conscience que mon rapide exposé est assez obscur et je vous invite viveent à vous documenter sur le net.
 
Ce truc c'est un projet que Sun développe depuis 1999, c'est le fruit de 3 ans d'efforts... Ca devrait révolutionner pas mal de chose.
 
Autre truc pour le débat programmation procédurale vs programmation objet... On peut tous très vite oublier la programmation procédurale.

[jfdsdjhfuetppo]--Message édité par Roco--[/jfdsdjhfuetppo]

ok, parce que je ne voyais pas trop comment ca pouvais marcher sinon ...
 
Tu as piqué ma curiosité. Je vais me documenté la dessus !
 
Si jamais tu entends parler d'autres conférences en France ou si la conférence à laquelle tu as assisté a lieu autre part dans quelques temps, tu pourrais prévenir avec un petit post sur le forum ?

Ben en fait ma boite reçoit très svt des invitations pour ce genre de conférence car elle fait partie de la "Sun Developper Connection".
 
A ce propos y'à une autre conférence très intéressante et, ouverte au public celle-ci, sur les webservices qui à l'air vraiment très intéressante avec SOAP, UDDI, WSDL et ebXML + pleins de trucs sur J2EE et les outils de dev comme Forte.
 
a voir : http://www.sun.fr/developpeurs/sdc/webservices/

je sais : en principe j'y vais (en tout cas le premier jour) !

Trop cool, faut que je demande à mon chef de m'inscrire (ça devrait pas poser de problème car c'est lui qui me l'a proposé).
 
On se verra là-bas alors

et la rapport avec les entity beans et leur language de requetes dans EJB 2.0
 
Et au niveau transactionnel le rapport avec JMS?
 
Pour la conférence, j'y allais aussi qd j'étais consultant. Maintenant c'est fini

ben en gros, si ce truc fonctionne bien, l'intérêt des EntityBean tels qu'ils sont définis actuellement sera plutot limité, tu crois pas ?
 
J'ai jamais trop apprécié les EntityBean. Pour moi, c'est une immonde usine à gaz, ou alors il faut passer un temps fou pour optimiser ce truc.
 
Donc si un truc pouvait les "remplacer", je serais plutot content !

bien d'accord. C'est justement pour ca que je posais la question figure toi. D'une manière pratique j'ai jamais dépassé EJB 1.1 toutes façons

Et bien justement dans cette conférence, il disait que avec les EJB tout le monde utilisait des session bean et que les autres modes de dév comme des Entity étaient très lourd...
 
Là je répéte juste ce que j'ai entendu car je n'ai jamais fais de EJB... et j'y connais vraiment rien!
 
Il paraît que grâce à cette outil le tps de dév va considérablement se réduire.
 
Ha oui, sinon c'est 100% compatible avec J2EE, JMS, et les autres "normes"...

[jfdsdjhfuetppo]--Message édité par Roco--[/jfdsdjhfuetppo]

 
moi quand j'entend "compatible avec J2EE", ca me fait marrer. Qu'est ce que ca veut dire compatble J2EE ???  
comment est ce qu'ils pourraient ne pas être compatible avec des packages ?
c'est du bon e-pipotage ca !

Le terme est de moi, pas de eux sorry...  
 
En fait JDO va aussi être intégré au prochain jdk. et il tourne sous J2EE, JMS, J2ME... enfin pour tous les systèmes...

benou a écrit a écrit :   je sais : en principe j'y vais (en tout cas le premier jour) !

Pourrais pas... C'est un jeudi et ça colle pas avec les prérogatives du services. Sorry.
 
Sinon pour JDO, ça à l'air bien. y a juste l'histoire de l'énorme cache qui me chatouille les oreilles. Je ne suis pas sûr de comprendre, mais est-ce que du point de vue BD, ça correspond pas à foutre un énorme verrou !

Génial j'ai trouvé la page à lire absolument :
 
http://www.libelis.com/index.jsp?next=jdo.html
 
c'est le président de cette société qui a mené la conférence.

je pense que c'est juste que les modifs BDD sont gardée en local jusqu'au commit qui met à jour la BDD. Ca te permet de manipuler les objets normalement et rapidement, puis de tout valider en un coup.

 
déjà lu hier soir !

Ben le problème c'est que cette gestion du cache est complétement transparente et sera gérée par la JVM...
 
Mais apparement ce cache est vraiment un truc super performant et optimisé depuis de très nombreuses années par Sun et Libelis.

J'espère, parce que le noeud du problème est là.

ben moi je pense que ca fonctionnera à la façon des transactions BDD : ca créra un espace dédié qui se mettra à jour et mettra à jour la BDD sur demande.
 
Y a moyen que ca marche bien !