Bryce's point makes perfect sense. The argument graphDb().createNode() gives the constructor an instance of Node, which contains a reference to the database, so there is no real need to additionally supply the database instance. Of course his example would have been less confusing if he'd written:
Node indexedNode = graphDb().createNode(); SortedTree st = new SortedTree( graphDb(), indexedNode, new IdComparator(), true, RelTypes.INDEXED_RELATIONSHIP.name() ); > From: [email protected] > Date: Fri, 16 Sep 2011 15:22:27 +0200 > To: [email protected] > Subject: Re: [Neo4j] Neo4j graph collections introduction of NodeCollection > interface > > 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 _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
