title: Neo4j output format
body: <p>After working with neo4j and now coming to the point of considering to make my own entity manager (object manager) to work with the fetched data in the application, i wonder about neo4j's output format.</p>
  
  <p>When i run a query it's always returned as tabular data. Why is this??
  Sure tables keep a big place in data and processing, but it seems so strange that a graph database can only output in this format.</p>
  
  <p>Now when i want to create an object graph in my application i would have to hydrate all the objects and this is not really good for performance and doesn't leverage true graph performace.</p>
  
  <p>Consider <code>MATCH (A)--&gt;(B) RETURN A, B</code> when there is one A and three B's, it would return:</p>
  
  <pre><code>A B
  1 1
  1 2
  1 3
  </code></pre>
  
  <p>That's the same A passed down 3 times over the database connection, while i only need it once and i know this before the data is fetched.</p>
  
  <hr>
  
  <p>Something like this seems great <a href="http://nigelsmall.com/geoff" rel="noreferrer">http://nigelsmall.com/geoff</a>
  a load2neo is nice, a load-from-neo would also be nice! either in the geoff format or any other formats out there <a href="https://gephi.org/users/supported-graph-formats/" rel="noreferrer">https://gephi.org/users/supported-graph-formats/</a></p>
  
  <p>Each language could then implement it's own functions to create the objects directly.</p>
  
  <p>To clarify:</p>
  
  <ul>
  <li>Relations between nodes are lost in tabular data</li>
  <li>Redundant (non-optimal) format for graphs</li>
  <li>Edges (relations) and vertices (nodes) are usually not in the same table. (makes queries more complex?)</li>
  </ul>
  
  <hr>
  
  <p>Another consideration (which might deserve it's own post), what's a good way to model relations in an object graph? As objects? or as data/method inside the node objects?</p>
  
  <hr>
  
  <p>@Kikohs<br>
  Q: What do you mean by "Each language could then implement it's own functions to create the objects directly."?<br>
  A: With an (partial) graph provided by the database (as result of a query) a language as PHP could provide a factory method (in C preferably) to construct the object graph (this is usually an expensive operation). But only if the object graph is well defined in a standard format (because this function should be simple and universal).</p>
  
  <p>Q: Do you want to export the full graph or just the result of a query?<br>
  A: The result of a query. However a query like <code>MATCH (n) OPTIONAL MATCH (n)-[r]-() RETURN n, r</code> should return the full graph.</p>
  
  <p>Q: you want to dump to the disk the subgraph created from the result of a query ?<br>
  A: No, existing interfaces like REST are prefered to get the query result.</p>
  
  <p>Q: do you want to create the subgraph which comes from a query in memory and then request it in another language ?<br>
  A: no i want the result of the query in another format then tabular (examples mentioned)</p>
  
  <p>Q: You make a query which only returns the name of a node, in this case, would you like to get the full node associated or just the name ? Same for the edges.<br>
  A: Nodes don't have names. They have properties, labels and relations. I would like enough information to retrieve A) The node ID, it's labels, it's properties and B) the relation to other nodes which are in the same result.</p>
  
  <p>Note that the first part of the question is not a concrete "how-to" question, rather "why is this not possible?" (or if it is, i like to be proven wrong on this one). The second is a real "how-to" question, namely "how to model relations". The two questions have in common that they both try to find the answer to "how to get graph data efficiently in PHP."</p>
  
  <hr>
  
  <p>@Michael Hunger</p>
  
  <p>You have a point when you say that not all result data can be expressed as an object graph. It reasonable to say that an alternative output format to a table would only be complementary to the table format and not replacing it.</p>
  
  <p>I understand from your answer that the natural (rawish) output format from the database is the result format with duplicates in it ("streams the data out as it comes"). I that case i understand that it's now left to an alternative program (of the dev stack) to do the mapping. So my conclusion on neo4j implementing something like this:<br>
  Pro's - not having to do this in every implementation language (of the application)<br>
  Con's - 1) no application specific mapping is possible, 2) no performance gain if implementation language is fast</p>
  
  <p>"Even if you use geoff, graphml or the gephi format you have to keep all the data in memory to deduplicate the results."<br>
  I don't understand this point entirely, are you saying that these formats are no able to hold deduplicated results (in certain cases)?? So infact that there is no possible textual format with which a graph can be described without duplication??</p>
  
  <p>"There is also the questions on what you want to include in your output?"<br>
  I was under the assumption that the cypher language was powerful enough to specify this in the query. And so the output format would have whatever the database can provide as result.</p>
  
  <p>"You could just return the paths that you get, which are unique paths through the graph in themselves".<br>
  Useful suggestion, i'll play around with this idea :)</p>
  
  <p>"The dump command of the neo4j-shell uses the approach of pulling the cypher results into an in-memory structure, enriching it".<br>
  Does the enriching process fetch additional data from the database or is the data already contained in the initial result?</p>