Problem with SDN loose typing in Neo4j vs java typing

[Fredrik Hultin]

Hi, I am using SDN 2.1.0.RC1.

When reading the documentation for neo4j and SDN, many of the example
uses the same type for the relations:

User -> HAS -> Permission
Where user and permission are nodes (and in SDN classes)

Here is the challange:
User -> HAS -> Pet
A fake case to show my point. If the user also has a relation HAS but
to another "type" of node (class)

This would be perfectly fine if only using neo4j since a cypher call
such as:
start user=node(userid) match user-[:HAS]->XX return XX
would return all the nodes with the has relation type (Pets and
Permissions) and it is later upp to the programmer to decide what to
do with the nodes (possibly check a property to decide what type of
node it is).

In SDN however this is not as easy since there is a java mapper in
between. Here is a simplified example:

public class User {
@RelatedTo(type="HAS")
Pet pet;

@RelatedTo(type="HAS")
Permission permission
}

This does not work in SDN. If you try to persist an object of this
class only one of the relations will be persisted. The same goes for
reading the data.

The difference between java and Neo4j is typing. Nodes in Neo4j are
not typed. When transitioning over into SDN the fake "__type__"
property does not seem to get enough attention. Today there seems to
be no check for the __type__ when accessing object via the
GraphRepository interfaces or via relations in classes. The result is
that you can get a java object with the "wrong" content. Or in other
words a node dressed with the "wrong" class.

The mapped User class above should probably be treated like this (but
under the hood not in code):

public class User {
@RelatedTo(type="HAS", className="Pet")
Pet pet;

@RelatedTo(type="HAS", className="Permission")
Permission permission
}

The same goes for the GraphRepository:
public interface UserRepository extends GraphRepository<User>{
public User findOne(Long id);
}
The repository would imply that any user returned from the findOne
also was of type User or it would not match at all, eg the cypher
query would need to be:
start n=node(id) where n.__type__=classname return n

I guess that for now I can workaround the problem by creating more
specific relation types:
User -> HAS_PERMISSION -> Permission

However I found that in our growing application not even this
specification was enough (in one place so far I still get duplicate
relations) so for now I will have to be even more specific:
User -> USER_PERMISSION -> Permission


Am I going about this the wrong way? I am still new within the graph
concept.

[Michael Hunger]

Fredrik,

this case has also been recently discussed in the Spring Forums and will be worked on. The solution here is to take the target class declaration (or rather the class hierarchy) into account when looking for
the end-nodes of the relationship. This will be enabled with an attribute on @RelatedTo(Via)

From a graph point of view, there are many ways of describing types in a graph, so there is not "one-right" solution, depends on the use-cases.
- a type - property
- incoming or outgoing rel-types
- place in the graph (path to the node)
- index entry

SDN tries to cater for some of those but the issue you have is a valid point, so thanks for reminding us.

HTH

Cheers

Michael

[Fredrik Hultin]

Do you remember the topic so that I can get up to speed? I searched
the forums before posting but could not find anything so I must have
searched for the wrong key words.

I agree that this is a difficult topic however I can not se why the
__type__ property would not suffice? I realize that you could infere
the type in many different ways but the __type__ property is written
by SDN on persisting the class and at that point there is not argument
on what type it is?

I might not understand the full scope here so I apologize for that ;)

Cheers
Fredrik

On Jun 4, 10:57 am, Michael Hunger <michael.hun...@neotechnology.com>
wrote:

[Michael Hunger]

Sure it would suffice, it just has to be done. We went for the simplest (and most performant) thing in the beginning which is to just check the rel-type.

But it makes sense in many cases to also filter on the target-type. It just won't be the default (as it is more costly).

Michael

[Michael Hunger]

The issues related to this are:

https://jira.springsource.org/browse/DATAGRAPH-250
https://jira.springsource.org/browse/DATAGRAPH-52
https://jira.springsource.org/browse/DATAGRAPH-53

And there are several spring forum post related to this.

It was mostly a time issue, but with Lasse ramping up we can solve more issues in a shorter timeframe.

Michael


Am 04.06.2012 um 13:00 schrieb Fredrik Hultin: