ヒント

Neo4j Wiki から

This page lists things you have to think about when writing code using neo4j.

[edit] Properties are not objects

The PropertyContainer interface, extended by the Node and Relationship interfaces, may suggest that properties are objects:

public interface PropertyContainer
{
	public Object getProperty( String key );
	public void setProperty( String key, Object value );
        ...
}

In fact, Neo4j properties are Java primitives with addition of String and arrays of those types. Have a look in the setProperty() documentation to get the details.

One consequence of this is that null is not accepted as a property value. And that you also never will get a null value back from a call to getProperty( String key ). Trying to use getProperty( String key ) on a property that does not exist will result in a RuntimeException. To avoid this, you can use getProperty( String key, Object defaultValue ) or check if the property exists using hasProperty( String key ).

Conclusion:

Neo4j stores Java primitives, Strings and arrays of Java primitives and Strings. Null values are not allowed.

[edit] Calculating path distances

When traversing a graph using a Traverser, the TraversalPosition will tell you (among other things) at which depth() you are in the traversal.

However, when traversing DEPTH_FIRST you can't be sure that this is the shortest path to the node. If that is what you want (and it probably is), you should go for a BREADTH_FIRST traversal order.


Of course, this applies when you write your own traversing code as well.


An example will show us what's happening:

Image:Gotcha-depth-breadth.png

Let's say we traverse this graph according to the following criteria:

  • start at the reference node
  • follow outgoing relationships
  • depth-first
  • stop at depth 2
  • all visited nodes are marked as such, and not visited any more (there could be a loop in the graph!)

Everything sounds fine, yes?!This is what may happen:

  1. starting at reference node
  2. following relationship ROOT 1
  3. visited Li
  4. at depth 1, following relationship KNOWS 2
  5. visited Peter
  6. stop at depth 2, going for the next relationship
  7. at depth 1,following relationship OWNS 4
  8. visited blaff
  9. stop at depth 2, going for the next relationship
  10. at depth 0, following relationship ROOT 0
  11. skipped Peter, node already visited
  12. no more relationships to traverse

This result may not be what you expected, with the woff node missing from the result!

Conclusion:

Depending on graph layout and purpose, choose the traversal order (depth/breadth-first) that suits the situation.

[edit] Incoming or outgoing relationships

Be aware of the Direction of traversals: INCOMING, OUTGOING or BOTH. If your traversals are returning nothing at all, you are maybe looking in the wrong direction!

Usually there is no problem keeping track of the relationship directions in your graph. But when promoting some code that was written for a more specific case to a generic position, it is easy to forget about this part.

Also relationships are traversed equally fast and efficient irregardless of the direction they are being traversed, so mirroring relationships in the reversed direction has no performance advantage; if anything, the opposite.

Conclusion:

Keep the relationship directions in mind, especially when changing the context of a piece of code.
Neo4j のサイト
ツールボックス