Hi Niels, I had wondered about having a collection interface that covered both nodes and relationships. There were a couple of reasons I didn't go with that right now, though well worthwhile discussing it and going with a GraphCollection super interface if it fits properly.
Firstly I wanted to get something "out there" so people could have a look, and having something that matched what IndexedRelationship currently required was easiest first step. Biggest thing specific in there to that functionality is the addNode method returning a relationship. The other issue was more wondering how a relationship collection would work. Say I have a relationship collection, and I have a relationship R1 between node A and B, how am I going to represent that relationship withing some graph based data structure that makes sense. There could be a node X that is part of the relationship collection data structure (e.g. tree) and that node could have an attribute that has the relationship id on it, but that doesn't seem like it would be very performant. There could be a relationship between X and A that also gave the relationship type of R1, so you could find the relationship based on that, but there isn't any guarantee of the relationship type being unique. What it would need to properly model it is the ability to have a relationship between X and R1, i.e. a relationship from a node to a relationship. If instead of being able to add any given relationship to the relationship collection you instead restrict it to being relationships matching a certain criteria from a given node then it is practically the same thing as a relationship expander. Or if you instead have a way through the relationship collection to create relationships from a given node to a set of other arbitrary nodes, with the relationship collection having a fixed relationship type and direction, then that is practically the current IndexedRelationship. I guess a way it could work is similar to IndexedRelationship, basically more general case of that class, where you have a method on the relationship collection createRelationship(startNode, endNode, relationshipType, direction) that was then stored in an internal data structure to create a pseudo relationship between the start and end, and then being able to iterate over this set of relationships. Not sure exactly what the use case of that would be. Maybe of more interest could be the same situation where the relationship type and direction are fixed, then you may have a "friend of" set of relationships that you create between arbitrary nodes and then iterate over all of those. I can't personally think of a good way of adding a set of arbitrary relationships into a collection stored in a graph data structure. Thoughts? Cheers Bryce P.S. Peter, I had thought to remove the passing in of the graph database and instead just getting it from the node, or only passing in the graph database and creating the node internally. On Sat, Sep 17, 2011 at 2:19 AM, Niels Hoogeveen <pd_aficion...@hotmail.com>wrote: > > Hi Bryce, > I really like what you are trying to achieve here. > One question: > Instead of having NodeCollection, why not have GraphCollection<T extends > PropertyContainer>. That way we can have collections of both Relationships > and Nodes. > Niels > > > Date: Fri, 16 Sep 2011 17:37:29 +1200 > > From: bryc...@gmail.com > > To: user@lists.neo4j.org > > Subject: [Neo4j] Neo4j graph collections introduction of NodeCollection > interface > > > > Hi, > > > > I had mentioned in a previous thread that I was working on introducing a > > NodeCollection interface to remove the dependency from > IndexedRelationship > > to SortedTree. I have an initial cut of this up now in my github repo: > > https://github.com/brycenz/graph-collections > > > > It would be great to get community feedback on this as I think that > having a > > well designed and common NodeCollection interface would help for multiple > > use cases, e.g. sortedTreeNodeCollection.addAll(linkedListNodeCollection) > > doing exactly what you think it would. > > > > IndexedRelationship now takes a node to index relationships from, a > > relationship type, and a direction, as well as a NodeCollection at > creation > > time. As in the unit tests this then leads to: > > > > Node indexedNode = graphDb().createNode(); > > SortedTree st = new SortedTree( graphDb(), graphDb().createNode(), new > > IdComparator(), true, RelTypes.INDEXED_RELATIONSHIP.name() ); > > > > IndexedRelationship ir = new IndexedRelationship( indexedNode, > > RelTypes.INDEXED_RELATIONSHIP, Direction.OUTGOING, st ); > > > > To create the IndexedRelationship. To later add nodes to the > relationship > > you need to create an instance of IndexedRelationship without the > > NodeCollection: > > > > IndexedRelationship ir = new IndexedRelationship( indexedNode, > > RelTypes.INDEXED_RELATIONSHIP, Direction.OUTGOING ); > > > > > > What this means from a NodeCollection implementation point of view is > that > > firstly it needs to use the NodeCollection.RelationshipType.VALUE > > relationship to connect from its internal data structure to the nodes > being > > added to the collection, and it needs to be able to recreate itself from > a > > base node that is passed into a constructor (that only takes the base > node). > > A node collection also needs to store its class name on the base node > for > > later construction purposes, as well as any other data required to > recreate > > the NodeCollection instance (in the case of SortedTree this is the > > comparator class, the tree name, and whether it is a unique index. > > > > Niels, you may want to have a good look over SortedTree, I have made a > few > > changes to it, mainly around introduction of a base node, and changing of > > the end value relationships. This could be cleaned up better, but I > wanted > > to start with minimal changes. > > > > Both IndexedRelationship and IndexedRelationshipExpander have no > > dependencies on SortedTree now, and should work with any properly > > implemented NodeCollection. I will be putting together a paged linked > list > > NodeCollection next to try this. > > > > Some future thoughts for NodeCollection, addition of as many of the > > java.util.Collection methods (e.g. addAll, removeAll, retainAll, > contains, > > containsAll) as well as an abstract base NodeCollection to help provide > > non-optimised support for these methods. > > > > Cheers > > Bryce > > _______________________________________________ > > Neo4j mailing list > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
