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).
> 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:
>> 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
>> Am 04.06.2012 um 10:05 schrieb 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.
