It is possible to grab an id from the id-generator, but then every call to GraphDatabaseService#getRelationshipById() will throw a NotFoundException.
> From: michael.hun...@neotechnology.com > Date: Thu, 7 Jul 2011 19:09:41 +0200 > To: user@lists.neo4j.org > Subject: Re: [Neo4j] Indexed relationships > > Why can't they should.n't it be possible to grab an id from the id-generator > on creation and store it as property? > > Sent from my iBrick4 > > > Am 07.07.2011 um 16:55 schrieb Niels Hoogeveen <pd_aficion...@hotmail.com>: > > > > > Hi Michael,I realize that the implementation of IndexedRelationship can in > > fact support returning relationships, and I have a preliminary version > > running locally now.The returned relationships can support all methods of > > the Relationship interface, returning the node pointing to the treeRoot as > > the startNode, and returning the node set as the key_value as the > > endNode.All relationship properties will be stored on the KEY_VALUE > > relationship pointing to the endNode.There is one caveat to this solution, > > the returned relationships cannot support the getId() method,and will throw > > an UnsupportedOperationException when being called.IndexedRelationship will > > implement Iterable<Relationship>.With these changes, it is possible to > > create an Expander and I am working right now to implement that.Niels > > > >> From: pd_aficion...@hotmail.com > >> To: user@lists.neo4j.org > >> Date: Thu, 7 Jul 2011 14:46:35 +0200 > >> Subject: Re: [Neo4j] Indexed relationships > >> > >> > >> Hi Michael, > >> > >> I haven't yet worked on an example. > >> > >> There are tests for the SortedTree implementation, > >> but didn't add those to the IndexedRelationship class, > >> which is simply a wrapper around SortedTree. > >> Having a test would have caught the error > >> that no relationship to the treeNode was created > >> (fixed that bug and pushed it to Git) > >> (note to self: always create a unit test, > >> especially when code seems trivial). > >> > >> There is no relationship expander that uses this. > >> The RelationshipExpander has a method Iterable<Relationship> expand(Node > >> node) > >> which cannot be supported, since there is no direct relationship from > >> startnode to endnode. > >> Instead there is a path through the index tree. > >> > >> It's not possible to support the original relationship-traversal API > >> since the IndexedRelationship class is not a wrapper around a node, > >> but a wrapper around the relationships of a certain RelationshipType in > >> the OUTGOING direction. > >> > >> As to the name of the class. > >> It is essentially an indexed relationship, > >> and not just a solution to the densely-connected-node problem. > >> An indexed relationship can also be used to maintain > >> a sorted set of relationships of any size, > >> and can be used to guarantee unicity constraints. Niels > >>> From: michael.hun...@neotechnology.com > >>> Date: Thu, 7 Jul 2011 13:27:00 +0200 > >>> To: user@lists.neo4j.org > >>> Subject: Re: [Neo4j] Indexed relationships > >>> > >>> Good work, > >>> > >>> do you have an example ready (and/or some tests that show how it works/is > >>> used) ? > >>> > >>> In creation, manual traversal and automatic traversal (i.e. is there a > >>> RelationshipExpander that uses it). > >>> > >>> And in the constructor if there is no relationship to the treeNode, you > >>> create a new one, but that new treeNode is not connected to the actual > >>> node? > >>> > >>> I'm not sure if it should support the original relationship-traversal API > >>> / methods (getRelationships(Dir,type), etc). > >>> > >>> Perhaps that IndexedRelationship should rather be just a wrapper around a > >>> SuperNode ? So probably rename it to "SuperNode(Wrapper) or > >>> HeavilyConnectedNode(Wrapper) ?) > >>> > >>> Cheers > >>> > >>> Michael > >>> > >>> Am 07.07.2011 um 12:51 schrieb Niels Hoogeveen: > >>> > >>>> > >>>> Finished the implementation of indexed relationships. The graph > >>>> collections component now contains the package > >>>> https://github.com/peterneubauer/graph-collections/tree/master/src/main/java/org/neo4j/collections/indexedrelationship, > >>>> containing the IndexedRelationship class. > >>>> This class can be used instead of regular relationships > >>>> when:relationships need to be stored in a particular sort ordera unicity > >>>> constraint needs to be guaranteed nodes become densely populated with > >>>> relationships. > >>>> The implementation is traverser friendly. Given a start nodes all end > >>>> nodes can be found by following four relationships types in outgoing > >>>> direction. Given an end node the start node can be found by following > >>>> these four relationship types in incoming direction. Of course this > >>>> functionality is also covered in the API. > >>>> Niels > >>>> > >>>>> From: pd_aficion...@hotmail.com > >>>>> To: user@lists.neo4j.org > >>>>> Date: Thu, 7 Jul 2011 02:36:29 +0200 > >>>>> Subject: Re: [Neo4j] Indexed relationships > >>>>> > >>>>> > >>>>> Pushed SortedTree to Git after adding a unit test and doing some > >>>>> debugging. > >>>>> TODO:Add API for indexed relationships using SortedTree as the > >>>>> implementation.Make SortedTree thread safe. > >>>>> With regard to the latter issue. I am considering the following > >>>>> solution. Acquire a lock (delete a non existent property) on the node > >>>>> that points to the root of the tree at the start of AddNode, RemoveNode > >>>>> and Delete. No other node in the SortedTree is really stable, even the > >>>>> rootnode may be moved down, turning another node into the new rootnode, > >>>>> while after a couple of remove actions the original rootnode may even > >>>>> be deleted. > >>>>> Locking the node pointing to the rootnode, prevents all other > >>>>> threads/transactions from updating the tree. This may seem restrictive, > >>>>> but a single new entry or a single removal may in fact have impact on > >>>>> much of the tree, due to balancing. More selective locking would > >>>>> require a prebalancing tree walk, determining the affected subtrees, > >>>>> lock them and once every affected subtree is locked, perform the actual > >>>>> balancing. > >>>>> Please let me hear if there are any objections to locking the node > >>>>> pointing to the tree as the a solution to make SortedTree thread safe. > >>>>> Niels > >>>>> > >>>>>> Date: Tue, 5 Jul 2011 08:27:57 +0200 > >>>>>> From: neubauer.pe...@gmail.com > >>>>>> To: user@lists.neo4j.org > >>>>>> Subject: Re: [Neo4j] Indexed relationships > >>>>>> > >>>>>> Great work Nils! > >>>>>> > >>>>>> /peter > >>>>>> > >>>>>> Sent from my phone. > >>>>>> On Jul 4, 2011 11:39 PM, "Niels Hoogeveen" <pd_aficion...@hotmail.com> > >>>>>> wrote: > >>>>>>> > >>>>>>> Made some more changes to the SortedTree implementation. Previously > >>>>>> SortedTree would throw an exception if a duplicate entry was being > >>>>>> added. > >>>>>>> I changed SortedTree to allow a key to point to more than one node, > >>>>>>> unless > >>>>>> the SortedTree is created as a unique index, in which case an > >>>>>> exception is > >>>>>> raised when an attempt is made to add a node to an existing key entry. > >>>>>>> A SortedTree once defined as unique can not be changed to a non-unique > >>>>>> index or vice-versa. > >>>>>>> SortedTrees now have a name, which is stored in the a property of the > >>>>>> TREE_ROOT relationship and in the KEY_VALUE relationship (a new > >>>>>> relationship > >>>>>> that points from the SortedTree to the Node inserted in the > >>>>>> SortedTree). The > >>>>>> name of a SortedTree can not be changed. > >>>>>>> SortedTrees now store the class of the Comparator, so a SortedTree, > >>>>>>> once > >>>>>> created, can not be used with a different Comparator. > >>>>>>> SortedTree is now an Iterable, making it possible to use it in a > >>>>>> foreach-loop. > >>>>>>> Since there are as of yet, no unit tests for SortedTree, I will create > >>>>>> those first before pushing my changes to Git. Preliminary results so > >>>>>> far are > >>>>>> good. I integrated the changes in my own application and it seems to > >>>>>> work > >>>>>> fine. > >>>>>>> Todo: > >>>>>>> Decide on an API for indexed relationships. (Community input still > >>>>>> welcome).Write unit tests.Make SortedTree thread safe (Community help > >>>>>> still > >>>>>> welcome). > >>>>>>> Niels > >>>>>>> > >>>>>>>> From: pd_aficion...@hotmail.com > >>>>>>>> To: user@lists.neo4j.org > >>>>>>>> Date: Mon, 4 Jul 2011 15:49:45 +0200 > >>>>>>>> Subject: Re: [Neo4j] Indexed relationships > >>>>>>>> > >>>>>>>> > >>>>>>>> I forgot to add another recurrent issue that can be solved with > >>>>>>>> indexed > >>>>>> relationships: guaranteed unicity constraints. > >>>>>>>>> From: pd_aficion...@hotmail.com > >>>>>>>>> To: user@lists.neo4j.org > >>>>>>>>> Date: Mon, 4 Jul 2011 01:55:08 +0200 > >>>>>>>>> Subject: [Neo4j] Indexed relationships > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> In the thread [Neo4j] traversing densely populated nodes we > >>>>>>>>> discussed > >>>>>> the problems arising when large numbers of relationships are added to > >>>>>> the > >>>>>> same node. > >>>>>>>>> Over the weekend, I have worked on a solution for the > >>>>>> dense-relationship-nodes using SortedTree in the neo-graph-collections > >>>>>> component. After some minor tweaks to the implementation of > >>>>>> SortedTree, I > >>>>>> have managed to get a workable solution, where two nodes are not > >>>>>> directly > >>>>>> linked by a relationship, but by means of a BTree (entirely stored in > >>>>>> the > >>>>>> graph). > >>>>>>>>> Before continuing this work, I'd like to have a discussion about > >>>>>> features, since what we have now is not just a solution for the dense > >>>>>> populated node issue, but is actually a full fledges indexed > >>>>>> relationship, > >>>>>> which makes it suitable for other purposes too. > >>>>>>>>> An indexed relationship can for example be used to maintain a sorted > >>>>>> set of relationships in the graph, that is not necessarily huge, but > >>>>>> large > >>>>>> enough to make sorting on internal memory too expensive an operation, > >>>>>> or > >>>>>> situations where only one out of a large number of relationships is > >>>>>> actually > >>>>>> traversed in most cases. > >>>>>>>>> There are probably more use cases for in-graph indexed > >>>>>>>>> relationships, > >>>>>> so I'd like to know what features are desirable and what API would > >>>>>> Neo4J > >>>>>> users appreciate. > >>>>>>>>> P.S. I still think it would be good to consider, if technically > >>>>>> possible, partitioning the relationship store per relationship type > >>>>>> and per > >>>>>> direction. The indexed relationship solution works, but is of course > >>>>>> slower > >>>>>> than a direct relationship, both with respect to insert time and > >>>>>> traversal > >>>>>> time. If dense relationships are never traversed going out of the dense > >>>>>> node, the extra structure maintained by the BTree is only extra burden. > >>>>>>>>> P.P.S. If there are people with experience to make an implementation > >>>>>> thread safe, please volunteer to help make the implementation > >>>>>> production > >>>>>> proof. > >>>>>>>>> Niels > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>> > >>>> _______________________________________________ > >>>> 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 _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
