I am going to stick as closely to the current implementation of traversers and where possible use code of the current implementation. As far as I can see, the current UniquenessFilter works well, so I am going to keep that setup for the new implementation. Indeed it should be: Node --FRIEND--> Node --PARENT--> Node Both FRIEND and PARENT are just RelationshipTypes, nothing fancy with intermediate nodes going on.
The iterator that returns the paths of the traversal should check if none of the nodes/relationships in the path have been deleted when returning. Locking things in the traverser is probably not a good idea, since it can easily lock large parts of the graph for an unknown amount of time. The traverser works lazily, so we cannot know in advance when and even if the iterator will be forwarded. Keeping nodes (potentially indefinitely) locked is not such a good idea. A traversal can never return more than temporary snapshots of the database. It can easily be that already returned paths have been deleted by the time the traversal ends, and new paths can be created which the traverser will not see, because that part of the graph has already been examinated. I don't see how the isolation levels found in an RDBMS can be implemented in graph dabase. There is no notion of range locks without having a schema, so phantom reads may always occur in traversals. Niels > Date: Fri, 29 Jul 2011 07:04:41 +0200 > From: cyuczie...@gmail.com > To: user@lists.neo4j.org > Subject: Re: [Neo4j] Composable traversals > > Hey Niels, > As they are composable, is java going to keep track of things, like if > recursive, in stack ? or in array/variables ? or the graph could keep track > of what's beep parsed so far, in-graph ? (I mean, this question applies for > non-composable too; personally i like the idea of in-graph keeping track of > those but maybe that would be implemented later at a higher level, so I > guess for now it will be in array/variables) > > Just making sure, in here: > " Node --FRIEND--> Node --> PARENT --> Node" > FRIEND and PARENT are both relationship types? > they are thus not intermediary nodes acting like they are relationships? > (which is actually what I do with bdb where the only elemental thing is the > Node, rels cannot be addressed ie. by ID) > > What happens while the traversers are executing and some other > thread/process is deleting something which the traverser added to to itself > as a valid node/path ? For example the first Node in "Node --FRIEND--> Node" > assuming that's where the traverser's currently at, is deleted... > Is there some notification/event or were they locked by traverser? or this > kind of issue will be dealt with later after traverser is implemented? > Are thee locks kept in-graph so they can be seen by other threads/processes > (mainly thinking processes that cannot access the same java resource ie. in > another jvm or computer tho accessing the same database - I guess this rules > out embedded?) ? if any locks... > > On Fri, Jul 29, 2011 at 1:30 AM, Niels Hoogeveen > <pd_aficion...@hotmail.com>wrote: > > > > > I'd like to take a stab at implementing traversals in the Enhanced API. One > > of the things I'd like to do, is to make traversals composable. > > > > Right now a Traverser is created by either calling the traverse method on > > Node, or to call the traverse(Node) method on TraversalDescription. > > > > This makes traversals inherently non-composable, so we can't define a > > single traversal that returns the parents of all our friends. > > > > To make Traversers composable we need a function: > > > > Traverser traverse(Traverser, TraversalDescription) > > > > My take on it is to make Element (which is a superinterface of Node) into a > > Traverser. > > > > Traverser is basically another name for Iterable<Path>. > > > > Every Node (or more generally every Element) can be seen as an > > Iterabe<Path>, returning a single Path, which contains a single > > path-element, the Node/Element itself. > > > > Composing traversals would entail the concatenation of the paths returned > > with the paths supplied, so when we ask for the parents of all our friends, > > the returned paths would take the form: > > > > Node --FRIEND--> Node --> PARENT --> Node > > > > 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
