Journal JDO : Quelle implémentation libre gère le XML pour la persistance ?

Posté par  .
Étiquettes : aucune
0
8
juin
2004
Bien l'bonjour à vous qui lisez mon premier journal.

Voilà, cela fait maintenant 4 jours complets que je suis à la recherche d'une implantation libre de JDO (Java Data Object, spec. de SUN) qui permette l'utilisation de fichiers XML pour la persistance.
Le résultat de cette recherche n'est pas très brillant. J'ai bien trouvé des implémentations, telles LiDO, mais seule la version commerciale intègre la persistance en XML. Il y a Hibernate, également, mais il ne semble pas gérer le XML :-(

Alors je vais me tourner vers vous, visiteur, pour vous demander un peu d'aide dans ce domaine, pour peu que cela vous soit familier.

Je vais reprendre depuis le début, et tenter de vous exposer mon besoin :

Je souhaite développer une application en JAVA.
  • Cette application va me permettre de gérer une liste d'objets, de les modifier, d'en créer d'autres, d'en supprimer, de les trier, et de les stocker.
  • Afin que l'application soit très facile à installer, je ne souhaite pas utiliser de base de donnée pour la persistance.
  • De plus, j'aimerai que les données sauvegardées soient facilement lisibles par tout autre logiciel, et par n'importe qui.
    C'est donc naturellement que je me suis orienté vers le format XML. Et comme je suis un gros fénéant, je ne souhaite pas non plus me prendre la tête avec le côté technique de la persistance (gestion des transactions incluse). J'ai donc trouvé JDO, une spécification SUN pour gérer la persistance des objets dans des tables de BDD, dans des fichiers, etc.

    Il ne reste plus qu'à trouver un implémentation libre de JDO... qui gère la persistance dans des fichiers XML.

    Tâche ardue.

    Merci d'avance pour vos commentaires/aides/réponses/solutions/critiques* et bonne journée !

    (* rayez les mentions inutiles)
    • # Je suis déjà dehors

      Posté par  (site web personnel) . Évalué à 2.

      LiDO ... une danseuse peut-être ?
      O.D.I.L ... qu'est-ce que ca peut bien vouloir dire ?
    • # HSQLDB

      Posté par  (site web personnel) . Évalué à 3.

      Pourquoi ne pas utiliser Hibernate avec une mini base de donnee du style HSQLDB ( http://hsqldb.sourceforge.net/(...) ) ? Il n'y a rien de plus a installer pour l'utilisateur et c'est super leger ...

      En plus, Hibernate c'est vraiment genial !
      • [^] # Re: HSQLDB

        Posté par  . Évalué à 1.

        yep !
        Je viens de jeter un oeil, ça a l'air vraiment pas mal ! Cependant, les données ne sont pas enregistrées dans des fichiers XML...

        Mais je garde cette URL car ça me semble vraiment intéressant. Peut-être que si les performances de la persistance en XML ne sont pas au rendez-vous, je passerais par cette mini base de donnée :-)

        Il me suffira de rajouter des options d'import/export en XML à mon application.

        Merci pour l'info !
    • # regarde du coté de castor

      Posté par  . Évalué à 2.

      http://castor.exolab.org(...)

      Je ne sais pas si c'est ce que tu recherches mais ca peut p-e t'aider
      • [^] # Re: regarde du coté de castor

        Posté par  . Évalué à 1.

        Ah, oui :)

        Effectivement, j'avais trouvé ça aussi. Ce qui me génait un peu, c'est le fait que Castor n'est pas une implémentation de la spec. JDO... même si ça fait un peu la même chose.

        Je pensais pouvoir trouver la même chose, mais respectant la spec. mais si je ne trouve pas, Castor sera certainement une des solutions que j'étudierai sérieusement.

        merci pour l'info :)
        • [^] # Re: regarde du coté de castor

          Posté par  . Évalué à 3.

          Le coté sympa de Castor, c que si tu as tes objets java, tu n'as plus qu'à écrire un fichier de mapping XML et hop, d'un coup, tu peux soit transformer tes objets java en message XML soit le message XML en objets java sans modification de code de tes objets.

          En plus y a un projet libre O2XMapper (c dans les outils tiers sur le site de Castor) qui permet de créer ton fichier de mapping avec une interface graphique.

          Voila, a+
    • # google dit

      Posté par  (site web personnel) . Évalué à 2.

      http://www.castor.org/(...)

      ça a l'air de faire ce que tu veux, et d'etre libre
      et google le trouve avec "jdo xml persistence" alors je me dis qu'il doit y avoir un hic
    • # Voila :

      Posté par  (site web personnel) . Évalué à 1.

      Y'a apache qui travail sur un truc. J'ai pas encore utilisé.
      Ca s'appelle ObJectRelationalBridge (1.0rc6).
      http://db.apache.org/ojb/(...)

      Si j'ai bien compris, il faut l'utiliser avec l'implémentation de référence de jun en attendant la version 2.0. Mais comme JDO c'est une inferface standard, y'a pas de pb ou le futur passage à la 2.0.
      • [^] # Oups

        Posté par  (site web personnel) . Évalué à 1.

        Autant pour moi,
        J'ai lu en diagonale, et j'ai loupé "persistance en xml". Désolé.
        Pour une BDD légère, je dit aussi HypersonicDB !
    • # C'est inclu dans le JDK

      Posté par  . Évalué à 3.

      Tout simplement en faisant de la sérialisation d'objet java en xml.

      XMLEncoder encoder =
      new XMLEncoder(
      new BufferedOutputStream(
      new FileOutputStream(filename)));
      encoder.writeObject(tonObjet);
      encoder.close();
      }

      Après il existe bien évidemment des solutions bien plus complexes :)
      • [^] # Re: C'est inclu dans le JDK

        Posté par  . Évalué à 1.

        Oui je sais ce n'est pas JDO mais ca a le mérite d'être très simple et integré au Jdk donc ca marche partout sans se prendre la tete. méthode KISS ;)

        http://whatis.techtarget.com/definition/0,,sid9_gci521694,00.html(...)
      • [^] # Re: C'est inclu dans le JDK

        Posté par  . Évalué à 1.

        Hm :)

        Oui, effectivement, j'ai commencé par vouloir faire ça... sauf qu'il faut aussi que je gère la recherche d'objet dans les classes... et les liaisons entre objets, pour faire des recherches liées... Et puis il faut gérer les transactions (commit, rollback...)...

        C'est pour ça que JDO est là : toute bonne implémentation gère un cache, possède un OQL (Obect Query Langage si je ne me trompe pas, c'est le pendant du SQL aux BDD appliqué aux Objets), permet de gérer les transactions...

        Du coup, je m'occupe uniquement du modèle objet de mon apli, je défini les classes, je fait mon IHM, je paramètre la persistance (fichiers, BDD...) et je me prend pas la tête avec tout le côté technique de la persistance.

        L'exemple que tu donnes est néanmoins intéressant lorsque l'on souhaite enregistrer un unique objet dans un fichier au format XML. Cependant, pour mon cas, il n'est pas applicable. Je peut être amené à manipuler plusieurs dizaines d'objets d'une même classe, liés à d'autre objets d'autres classes etc.

        Merci quand même pour le petit exemple :-)
        • [^] # Re: C'est inclu dans le JDK

          Posté par  . Évalué à 1.

          En fait tu peux tout a fait sérialiser des graphes d'objets, donc des références entre objets aussi.

          Il existe différentes techniques pour stocker des references entre objets sérialisés dans différents fichiers, enfin tout ca pour dire que c'est possible :)

          Effectivement si on rajoute les transactions ca devient plus délicat.

          Quand à JDO, cela ne m'a pas convaincu pour l'instant ;) la communauté java discute pas mal des différentes technos offertes pour la persistance des données ... et ca trolle dur

          Si tu googles un peu tu trouveras des jolies guerres de religion jdo / j2ee / hibernate / { etc ... }

          Mon opinion c'est que c'est la prise de tete assurée pour l'instant, c'est pas encore super au point.

          Je te conseille vivement des solutions alternatives, plus "simples", en l'occurence hibernate pour la persistance et le mapping relationnel objet couplé à un sgbd qui supporte le stockage en flat. Je crois bien avoir vu un sgbd libre qui faisait du stockage en xml, mais ma mémoire me fait défaut.

          Hibernate fonctionne très bien, la doc est de très bonne facture et la communauté vivante.

          mes 0,02? :)
    • # native XML database

      Posté par  . Évalué à 2.

      Et pourquoi pas une base de données xml? Du type:
      http://xml.apache.org/xindice/(...)
      C'est pas JDO mais cela pourrait peut-être t'intéresser? (j'ai pas testé soyons honnête)
      Mais ceci dit c'est vrai qu'en ce moment java et la persistence c'est un noeud de vipères. En fait les solutions sont toutes intéressantes mais c'est une certaine séparation des taches qui émerge. Un certaine conception du code. Et ça fait beaucoup de bien... Je commence un peu à regarder du côté de hibernate et je dois dire qu'avec Spring cela donne des modèles d'une grande propreté et où on a quand même pas mal l'impression de gagner du temps. Mais... c'est pas JDO, c'est pas une norme SUN.
      ps : JDO 1 ou 2? Il y a aussi cela en vue je crois? A savoir que jdo va gagner une grande richesse dans peu de temps qd auront achevé les specs de jdo. Mais .. "peu de temps" chez Sun c'est quoi 2? 3ans? Si tu peux attendre jusque là.
    • # Prevayler

      Posté par  . Évalué à 1.

      Je te suggere d'utiliser ceci

      http://www.prevayler.org/wiki.jsp(...)

      Prevayler is the free-software Prevalence layer for Java.

      Ridiculously simple, Prevalence is by far the fastest and most transparent persistence, fault-tolerance and load-balancing architecture for Plain Old Java Objects (POJOs).


      Le principe de cette solution si je l'ai bien compris est de gérer l'ensemble des instances de tes objets dans la RAM. On peut faire un snapshot à n'importe quel moment, pour gérer les crashs etc ...

      Pas de fichier de configuration fleuve, l'ensemble de la librairie ne doit pas dépasser une centaine de Ko. le principe est simple à toi de voir .

      Lire la FAQ pour les sceptiques
      http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ(...)

    Suivre le flux des commentaires

    Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.