Re: [Neo4j] Neo4j graph collections introduction of NodeCollection interface
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.comwrote: Hi Bryce, I really like what you are trying to achieve here. One question: Instead of having NodeCollection, why not have GraphCollectionT 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
Re: [Neo4j] Neo4j graph collections introduction of NodeCollection interface
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.comwrote: 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.comwrote: Hi Bryce, I really like what
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 bryc...@gmail.com 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 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
Re: [Neo4j] Neo4j graph collections introduction of NodeCollection interface
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: peter.neuba...@neotechnology.com Date: Fri, 16 Sep 2011 15:22:27 +0200 To: user@lists.neo4j.org 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 bryc...@gmail.com 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 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
Re: [Neo4j] Neo4j graph collections introduction of NodeCollection interface
Hi Bryce, I really like what you are trying to achieve here. One question: Instead of having NodeCollection, why not have GraphCollectionT 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
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.comwrote: Hi Bryce, I really like what you are trying to achieve here. One question: Instead of having NodeCollection, why not have GraphCollectionT 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
[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
