Also, since you can do node.getGraphDatabase(), I think we don't need to pass in the graphdb instance in new SortedTree( graphDb(), graphDb().createNode(), new IdComparator(), true, RelTypes.INDEXED_RELATIONSHIP.name() ); ?
Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://startupbootcamp.org/ - Öresund - Innovation happens HERE. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Fri, Sep 16, 2011 at 7:37 AM, Bryce <[email protected]> wrote: > 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 > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
