Hi Niels, Probably is a good idea. I will try to get something done around that soon, flat out with work issues/features at present (including a "nice" concurrency bug, argh).
Cheers Bryce On Wed, Sep 21, 2011 at 2:01 AM, Niels Hoogeveen <pd_aficion...@hotmail.com>wrote: > > Hi Bryce, > Sorry for the late response. > I understand it's difficult to come up with a really good use-case for > making NodeCollection more general in the context of IndexedRelationships, > but I like to think of that interface as something we can eventually use for > all sorts of collections, not just the ones derived from SortedTree. > There is of course the issue that relationships can not attach to > relationships, so collections of relationships will need to be addressed by > Id. This is not necessarily a bad thing, because it decouples the container > and the elements. In other words the container knows what elements it > contains, but the elements don't know in what containers they are placed. > Another option would be to create shadow nodes for contained relationships. > Instead of adding a relationships to the collection, its shadow node is > added and both the shadow node and the relationship contain pointers > (properties with Id values) towards each other. > I think it would be best if we do indeed create a GraphCollection interface > parameterized by <T extends PropertyContainer> even if that type parameter > for now is always a Node. It doesn't add much complexity now to do it, and > later on we may regret it and by then it becomes harder to do because there > is an installed base. > Niels > > > Date: Sat, 17 Sep 2011 14:19:04 +1200 > > From: bryc...@gmail.com > > To: user@lists.neo4j.org > > Subject: Re: [Neo4j] Neo4j graph collections introduction of > NodeCollection interface > > > > 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 > > _______________________________________________ > 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
