While working on Enhanced API, I realize two crucial method are missing on the 
Node interface of the standard API:

RelationshipType[] getRelationshipTypes();
RelationshipType[] getRelationshipTypes(Direction);

For Enhanced API, I'd like to be able to plug in different Relationship 
implementations (eg. SortedRelations and HyperRelations). 

Doing so is sort of possible, but only by cluttering a class called ElementImpl 
with all sorts of logic 
related to those different Relationship implementations (not the place where it 
belongs). 

The neat way would be to dispatch on RelationshipType and have the different 
Relationship implementations handle that logic.

The API for PropertyContainer on the other hand does provide a method similar 
to what I am asking for: PropertyContainer#getPropertyKeys(). 

I realize this request cannot be honored without changing the record layout of 
the neo4j store, which has a major impact.

However, there is already good reason to reconsider the record layout of the 
relationship store
to solve the issue of densely connected nodes. 

To properly solve the densely connected node issue, relationships should be 
partitioned by relationship type and by direction. 

That way only those Relationships belonging to a RelationshipType that 
contributes to the densely connectedness will take time to load, 
while other Relationships can be fetched fast.

Such partitioning immediately provides the meta information I am asking for.

Such meta information (as exists for properties), has value beyond its use in 
the Enhanced API. 

I would eg. like to be able to present a form with the property keys and 
RelationshipTypes associated with a particular Node, 
and on request load the content belonging to a property key or a 
RelationshipType. 

For property keys this is possible, but for RelationshipTypes all relationships 
need to be fetched 
to know which RelationshipTypes are associated with a particular node. 

Especially for RelationshipTypes with many instances connected to one Node this 
is not a suitable solution 
and runs counter to the need to load those relationships on request.

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

Reply via email to