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 <[email protected]>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 > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
