2010-02-05 8 views

Répondre

2

Je ne crois pas qu'il existe quelque chose là-bas pour cela, pas comme il ya quelques mois lorsque vous jouez avec elle. D'après ce que j'ai vu, il y a 2 roadblocks principaux:

  1. XML est hiérarchique, vous ne pouvez pas représenter les données graphiques facilement dans ce format.
  2. Manque d'identifiants explicites pour les noeuds. Même si les identifiants implicites existent, ce serait comme utiliser ROWID dans Oracle pour l'import/export ... pas garanti pour être le même.

Certaines personnes ont suggéré que GraphML serait le bon format pour cela, je suis d'accord. Si vous n'avez pas de structures graphiques et que vous seriez bien représenté dans un format XML/hiérarchique ... eh bien, c'est juste de la malchance. Puisque la majorité des utilisateurs qui s'attaqueraient à ce genre de tâche d'amélioration utilisent des données qui ne seraient pas stockées de cette façon, je ne vois pas de solution XML sortir ... plus susceptible de voir un format supportant toutes les utilisations en premier.

+2

Je ne suis pas exactement votre point. XML est un métalangage. GraphML est simplement une instance d'un langage de balisage XML, spécifiquement utilisé pour représenter des données graphiques. Ainsi est RDF et XML Topic Maps (XTM). Il n'y a aucune limitation au XML en soi pour représenter les graphiques, c'est-à-dire que tout langage de balisage SGML ou XML qui contient des liens le fait déjà. Par exemple, DocBook ** ressemble ** à un format de document hiérarchique, mais étant donné qu'il contient des liens, il peut également représenter un graphique, tout comme XHTML. –

+2

(Obtention de la règle d'édition de 5 minutes.) Comme pour les ID de noeud explicites ou implicites, il s'agit d'un problème d'implémentation. La plupart des langages de balisage graphique ont déjà des ID sur les éléments de niveau supérieur, et il est possible d'ajouter xml: id à n'importe quel balisage. L'exportation de Neo4j vers n'importe quel balisage ne devrait pas poser de problème, c'est juste une sérialisation, comme l'a indiqué Peter Neubauer ci-dessus. –

21

Je suis d'accord, GraphML est la solution, si vous n'avez pas de problèmes avec la verbosité de XML. Une façon simple de le faire est d'ouvrir le graphique Neo4j de Gremlin, où graphml est le format d'importation par défaut/export, quelque chose comme

 
peters: ./gremlin.sh 

gremlin> $_g := neo4j:open('/tmp/neo4j') 
==>neograph[/tmp/neo4j, vertices:2, edges:1] 
gremlin> g:save('graphml-export.xml') 

Comme décrit here

Est-ce que résoudre votre problème?

+0

votre lien me lie à une page wiki github vierge. Peut-être que vous vouliez dire cette page? http://github.com/tinkerpop/gremlin/wiki/Neo4j-Graph-Database – mmay

+3

Les informations actuelles sur le chargement/l'enregistrement depuis/vers Gremlin sont maintenant disponibles ici: https: // github.com/tinkerpop/gremlin/wiki/Gremlin-Methods – nawroth

+0

pourquoi ne pas modifier la réponse d'origine pour réparer l'URL alors? –

20

Avec Blueprints, il suffit de faire:

Graph graph = new Neo4jGraph("/tmp/mygraph"); 
GraphMLWriter.outputGraph(graph, new FileOutputStream("mygraph.xml")); 

Ou, avec Gremlin (qui fait la même chose dans le dos):

g = new Neo4jGraph('/tmp/mygraph'); 
g.saveGraphML('mygraph.xml'); 

Enfin, au constructeur pour Neo4jGraph, vous pouvez aussi passer dans une instance GraphDatabaseService.

0

Jetez un oeil à NoSqlUnit Il dispose d'outils pour convertir GraphML-neo4j et retour.

En particulier, il y a com.lordofthejars.nosqlunit.graph.parser.GraphMLWriter et com.lordofthejars.nosqlunit.graph.parser.GraphMLReader qui lisent/écrivent des fichiers XML vers/depuis une base de données neo4j.

+1

@jpp Eh bien, je peux référencer la source pour des fichiers java spécifiques, mais ce sont des classes avec des centaines de lignes de code, donc je ne vais pas redoubler ce code ici. – Stewart