#14: Specify the semantics of relationship types
--------------------------+-------------------------------------------------
Reporter: emil | Owner: emil
Type: task | Status: assigned
Priority: major | Milestone: neo-1.0
Component: neo-core api | Resolution:
Keywords: |
--------------------------+-------------------------------------------------
Comment (by emil):
One of the problems is that with extensible relationship types, everything
just got much more cumbersome (which means more code (annoying) and easier
to introduce subtle bugs (fatal)) when it comes to checking reltype
equality. For example, without extensible relationship types, here's how
you would check if a relationship is of a certain type:
{{{
if ( rel.getType() == RelTypes.BELONGS_TO )
{
// do stuff
}
}}}
Beautiful. Well, this doesn't work any more, since the semantics of
reltype equivalence has changed. With extensible reltypes, the only
correct way to check whether a relationship type is the same as another
type is by checking for whether their ''names'' are equal, i.e:
{{{
if ( rel.getType().name().equals( RelTypes.BELONGS_TO.name() ) )
{
// do stuff
}
}}}
There's like a million ways to screw that up, and the compiler usually
won't warn you (since equals() accepts an Object parameter).
So I [changeset:405 just added] a convenience method {{{isType()}}} to
Relationship.
Now:
{{{
if ( rel.isType( RelTypes.BELONGS_TO ) )
{
// do stuff
}
}}}
Typesafe, compiler-friendly, etc.
This simple and seemingly-obvious addition actually goes quite a long ways
to alleviating my worries about the API usability impact of extensible
relationship types.
--
Ticket URL: <https://trac.neo4j.org/ticket/14#comment:4>
neo4j.org <http://trac.neo4j.org/>
The Neo4J.org Issue Tracker_______________________________________________
Neo mailing list
[email protected]
http://lists.neo4j.org/mailman/listinfo/user
