Re: [Neo4j] NodeType (continued from Disqus)

[Peter Neubauer]

Jason,

that is a very interesting thought, which is right down our current thinking of adding "labels" (since types imply inheritance and other nasty beasts) to nodes, backed by indexes. We are going to tackle these after 1.9, and will discuss that on this list. Basically the thought is to back Labels by Automatic Indexes, and thus be able to assign label(s) to nodes and then ask set-type queries that will be triggering index queries automatically if necessary. We hope that will take care of 95% of the current cases where you need indexing.

WDYT?

Cheers,

/peter neubauer

G:  neubauer.peter
S:  peter.neubauer
P:  +46 704 106975
L:   http://www.linkedin.com/in/neubauer
T:   @peterneubauer

Neo4j 1.8 GA - http://www.dzone.com/links/neo4j_18_release_fluent_graph_literacy.html

On Wed, Oct 31, 2012 at 3:41 PM, jasonsirota <jsi...@theknot.com> wrote:

There's a question in the disqus comments of the Traversal tutorial on how to implement Traversal Description for NodeTypes vs. Relationship types. nawroth indicated (to me) that the proper way to model node type traversals is by their RelTypes. So that got me thinking about NodeTypes. I did a quick search of the forum but haven't seen this question answered.

Is there a theoretical/performance limitation to a native representation of a NodeType similar to the RelationshipType? Several examples in the tutorial imply that NodeType is a basic attribute of a Node, i.e. "Person", "StatusUpdate". Take a "favorites" system in an ecommerce use case where the user can favorite several different categories of objects. I think of the graph like this naturally:

(UserA) --[favorites]--> (BookA)

(UserA) --[favorites]--> (BookB)

(UserB) --[favorites]--> (BookA)

(UserB) --[favorites]--> (BookB)

(UserA) --[favorites]--> (Toy)

(UserA) --[favorites]--> (Blanket)

If I want to say "find me all the Books that users who favorited Book A also favorited ("2 People who liked Book A also liked Book B")

In order to traverse that graph using RelTypes, I'd have to do something more like this:

(UserNodeA) --[favorites]--> (FavoriteNode) --[book_favorite_of]--> (BookNodeA)

(UserNodeA) --[favorites]--> (FavoriteNode) --[book_favorite_of]--> (BookNodeB)

(UserNodeB) --[favorites]--> (FavoriteNode) --[book_favorite_of]--> (BookNodeA)

(UserNodeB) --[favorites]--> (FavoriteNode) --[book_favorite_of]--> (BookNodeB)

(UserNode) --[favorites]--> (FavoriteNode) --[toy_favorite_of]--> (ToyNodeA)

(UserNode) --[favorites]--> (FavoriteNode) --[blanket_favorite_of]--> (BlanketNodeA)

Is this the correct way to model for this use case? Is there a better one?

--
 
 

[RickBullotta]

The "identify by relationships" approach didn't work for us.  We needed to be able to determine a node's "type" directly from the node itself, particularly in the case where the node was returned from an index search.  A pattern that we used, which doesn't require much extra storage, is to leverage the fact the Java enums are actually classes, and to use an explicit enum <-> int code mapping, and assign the int property value to the node.  This way you can use enums in a safe and durable way as a type identifier.  Here's an example:

public static enum ThingworxPrincipalTypes {

        Unknown(UNKNOWN_NODE_TYPE),

User(1),

Group(2),

SuperUser(3),

Thing(4);

private int _code;

        

        private ThingworxPrincipalTypes(int code) {

        _code = code;

        }

        

        public int code() {

        return _code;

        }

        

        public static ThingworxPrincipalTypes fromCode(int code) {

       

        for(ThingworxPrincipalTypes type : ThingworxPrincipalTypes.values()) {

        if(type.code() == code)

        return type;

        }

       

        return null;

        }

        public static ThingworxPrincipalTypes fromNode(Node node) {

Integer code = (Integer)node.getProperty(CommonPropertyNames.PROP_PRINCIPALTYPE,UNKNOWN_NODE_TYPE);

if(code != null) {

         for(ThingworxPrincipalTypes type : ThingworxPrincipalTypes.values()) {

         if(type.code() == code)

         return type;

         }

}        

        return null;