Re: [Neo4j] Attributes or Relationship Check During Traversal

[Mattias Persson]

I'd probably go for that as well.

It's harder to go with a gut feeling for the case where you have many
categories... it may be better to go with relationships then, because you
gain the traversal aspect of it which you don't really get if you go with
properties.

2010/8/1 rick.bullo...@burningskysoftware.com 
rick.bullo...@burningskysoftware.com

 My instinct says a boolean property would be easier and faster, but ymmv.

 - Reply message -
 From: Alex D'Amour adam...@iq.harvard.edu
 Date: Sun, Aug 1, 2010 2:32 pm
 Subject: [Neo4j] Attributes or Relationship Check During Traversal
 To: Neo user discussions user@lists.neo4j.org

 Hello all,

 I have a question regarding traversals over a large graph when that
 traversal depends on a discretely valued attribute of the nodes being
 traversed.

 As a small example, the nodes in my graph can have 2 states -- on and off.
 I'd like to traverse over paths that only consist of active nodes. Since
 this state attributes can only take 2 values, I see two possible approaches
 to implementing this:

 1) Use node properties, and have the PruneEvaluator and filter Predicate
 check to see whether the current endNode has a property called on.

 2) Create a state node which represents the on state. Have all nodes that
 are in the on state have a relationship of type STATE_ON incoming from
 the
 on node. Have the PruneEvaluator and filter Predicate check whether the
 node has a single relationship of type STATE_ON, INCOMING.

 Which is closer to what we might consider best practices for Neo4j? The
 problem I see in implementation 1 is that that traversal has to hit the
 property store, which could slow things down. The problem with 2 is that
 there can be up to #nodes relationships coming from the on state node, and
 making this more efficient by setting up a tree of on state nodes seems
 to
 be manually replicating something that the indexing service has already
 accomplished.

 Also, how efficiently would each of these two implementations exploit
 caching (or is this irrelevant?)?

 Finally, would your answer change if we generalized this to a larger number
 of categories?

 Thanks,
 Alex
 ___
 Neo4j mailing list
 User@lists.neo4j.org
 https://lists.neo4j.org/mailman/listinfo/user

 ___
 Neo4j mailing list
 User@lists.neo4j.org
 https://lists.neo4j.org/mailman/listinfo/user




-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

[Neo4j] Attributes or Relationship Check During Traversal

[Alex D'Amour]

Hello all,

I have a question regarding traversals over a large graph when that
traversal depends on a discretely valued attribute of the nodes being
traversed.

As a small example, the nodes in my graph can have 2 states -- on and off.
I'd like to traverse over paths that only consist of active nodes. Since
this state attributes can only take 2 values, I see two possible approaches
to implementing this:

1) Use node properties, and have the PruneEvaluator and filter Predicate
check to see whether the current endNode has a property called on.

2) Create a state node which represents the on state. Have all nodes that
are in the on state have a relationship of type STATE_ON incoming from the
on node. Have the PruneEvaluator and filter Predicate check whether the
node has a single relationship of type STATE_ON, INCOMING.

Which is closer to what we might consider best practices for Neo4j? The
problem I see in implementation 1 is that that traversal has to hit the
property store, which could slow things down. The problem with 2 is that
there can be up to #nodes relationships coming from the on state node, and
making this more efficient by setting up a tree of on state nodes seems to
be manually replicating something that the indexing service has already
accomplished.

Also, how efficiently would each of these two implementations exploit
caching (or is this irrelevant?)?

Finally, would your answer change if we generalized this to a larger number
of categories?

Thanks,
Alex
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user