Et oui je me lance dans un nouveau projet, après OpenIM http://open-im.net(...) me voila sur la trace d'une lib de persistence XML (ou une bd XML ca dépend comment on voit les choses)
Wai, j'ai regardé, il y a rien de super du coté opensource. Mis à part XMLDB, mais je le sens pas trop. Je compte utiliser un mécanisme de persistence objet (via Hibernate), utiliser des lib existante pour XPath, XQuery et XUpdate, et m'appuyer sur cocoon. Donc en fait le soft va être assez simple, il s'agit juste de bien faire la sauce.
Si t'as des retours là dessus, cela peut m'intéresser... Le jour où je me déciderai à occuper mon chômage en me lançant dans mon idée d'appli de gestion de CV, il me faudra une couche de persistence xml je pense (mais j'hésite encore :-) )
Oui je connais bien les 3 et c'est pour cela que je me suis lancé dans ce projet.
Castor est un peu HS par rapport à ma problèmatique.
Xindice & Exist, sont dans le sujet, mais dans mon cas, je ne veux pas developper la couche transactionnelle et compte reposer sur un SGBDR traditionnel.
Ok cela risque d'etre plus lent qu'une implem native, mais c'est plus fiable et plus simple à mettre en oeuvre. Mon objectif n'est pas la performance brute, même si cela rentre en ligne de compte.
A terme, on pourrait envisager de developper une couche stockage ou une interface vers les BDXML pour gagner en vitesse.
fallait le dire, que c'était du Java ! Tu veux faire quoi, en vrai (parce que la persistance, c'est le concept haut-niveau) ?
- Sauver tes objets Java en XML ? Utilises les XMLEncoder et XMLDecoder fournis avec ton JDK.
- Parser un fichier de config écrit en XML ? Utilises le digester Apache.
- Obtenir une bijection entre tes objets Java et tes fichiers XML ? Effectivement, dans ce cas-là, Hibernate est une bonne solution, mais tu vas devoir te plonger dans les arcanes de ces mécanismes, de la modification à chaud de bytecode, et du mapping Objet/Data. Bon courage ;-)
(En gros) Je veux faire une implementation DOM qui au lieu d'etre sauvée sur disques est stockée dans la une bdd.
Pas mal d'avantages : on peut avoir une notion de trasaction (modifier plusieurs section de documents et faire un commit par exemple), gerer certaine zone d'un document (et ne pas charger tout le fichier en mémoire) à l'aide des requete XPath/Xquery (pour lire certaine zone du document, ou faire des recherche dans les documents). De plus cela permet de s'interfacer en transparence avec des outils existant de gestion de flux XML.
Mais il n'est pas vraiment question de faire du mapping objet java<=>xml.
(En gros) Je veux faire une implementation DOM qui au lieu d'etre sauvée sur disques est stockée dans la une bdd.
Je ne vois pas du tout l'intérêt. pourquoi ne pas, par exemple, stocker ton document XML dans un annuaire Ldap, par exemple, qui offre une plus grande ressemblance de format ?
Et pourquoi ne pas décomposer ton fichier XML en fragments ? il me semble qu'il existe pour cela une spécification du W3C, mais je n'en suis pas si sûr.
Pas mal d'avantages : on peut avoir une notion de trasaction (modifier plusieurs section de documents et faire un commit par exemple),
La transaction est la béquille de l'informatique.
gerer certaine zone d'un document (et ne pas charger tout le fichier en mémoire) à l'aide des requete XPath/Xquery (pour lire certaine zone du document, ou faire des recherche dans les documents).
Il me semble que XQuery devrait pouvoir faire ça d'emblée, non ?
De plus cela permet de s'interfacer en transparence avec des outils existant de gestion de flux XML
# Re: XML Persistence
Posté par Ramso . Évalué à 2.
[^] # Re: XML Persistence
Posté par Alexis Agahi . Évalué à 2.
[^] # Re: XML Persistence
Posté par B r u n o (site web personnel) . Évalué à 2.
Castor Xml http://www.castor.org/xml-framework.html(...)
Apache Xindice http://xml.apache.org/xindice/(...)
eXist http://exist-db.org/(...)
Si t'as des retours là dessus, cela peut m'intéresser... Le jour où je me déciderai à occuper mon chômage en me lançant dans mon idée d'appli de gestion de CV, il me faudra une couche de persistence xml je pense (mais j'hésite encore :-) )
[^] # Re: XML Persistence
Posté par Alexis Agahi . Évalué à 2.
Castor est un peu HS par rapport à ma problèmatique.
Xindice & Exist, sont dans le sujet, mais dans mon cas, je ne veux pas developper la couche transactionnelle et compte reposer sur un SGBDR traditionnel.
Ok cela risque d'etre plus lent qu'une implem native, mais c'est plus fiable et plus simple à mettre en oeuvre. Mon objectif n'est pas la performance brute, même si cela rentre en ligne de compte.
A terme, on pourrait envisager de developper une couche stockage ou une interface vers les BDXML pour gagner en vitesse.
# Re: XML Persistence
Posté par Nicolas Delsaux (site web personnel) . Évalué à 2.
- Sauver tes objets Java en XML ? Utilises les XMLEncoder et XMLDecoder fournis avec ton JDK.
- Parser un fichier de config écrit en XML ? Utilises le digester Apache.
- Obtenir une bijection entre tes objets Java et tes fichiers XML ? Effectivement, dans ce cas-là, Hibernate est une bonne solution, mais tu vas devoir te plonger dans les arcanes de ces mécanismes, de la modification à chaud de bytecode, et du mapping Objet/Data. Bon courage ;-)
[^] # Re: XML Persistence
Posté par Alexis Agahi . Évalué à 2.
Pas mal d'avantages : on peut avoir une notion de trasaction (modifier plusieurs section de documents et faire un commit par exemple), gerer certaine zone d'un document (et ne pas charger tout le fichier en mémoire) à l'aide des requete XPath/Xquery (pour lire certaine zone du document, ou faire des recherche dans les documents). De plus cela permet de s'interfacer en transparence avec des outils existant de gestion de flux XML.
Mais il n'est pas vraiment question de faire du mapping objet java<=>xml.
Merci pour les encouragements, je me lance la :)
[^] # Re: XML Persistence
Posté par Nicolas Delsaux (site web personnel) . Évalué à 1.
Je ne vois pas du tout l'intérêt. pourquoi ne pas, par exemple, stocker ton document XML dans un annuaire Ldap, par exemple, qui offre une plus grande ressemblance de format ?
Et pourquoi ne pas décomposer ton fichier XML en fragments ? il me semble qu'il existe pour cela une spécification du W3C, mais je n'en suis pas si sûr.
Pas mal d'avantages : on peut avoir une notion de trasaction (modifier plusieurs section de documents et faire un commit par exemple),
La transaction est la béquille de l'informatique.
gerer certaine zone d'un document (et ne pas charger tout le fichier en mémoire) à l'aide des requete XPath/Xquery (pour lire certaine zone du document, ou faire des recherche dans les documents).
Il me semble que XQuery devrait pouvoir faire ça d'emblée, non ?
De plus cela permet de s'interfacer en transparence avec des outils existant de gestion de flux XML
Gni ?
[^] # Re: XML Persistence
Posté par Alexis Agahi . Évalué à 1.
Ldap ne gere pas les transactions et n'est pas vraiment optimisé en écriture et pis merde faut arreter avec LDAP.
La transaction est la béquille de l'informatique.
Euh. Allo?
Il me semble que XQuery devrait pouvoir faire ça d'emblée, non ?
Tout dépend de l'implem DOM (cqfd)
Gni ?
Gnu?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.