Well, I've got none of those concerns really. Just the fact that TraversalDescription is viewed as "that other" traversal framework makes it slightly odd to use its interface in the core API. When it will be _the_ framework, or another one is built upon it (I sometimes more look at it as an engine which one can build a better API on) something like what you propose will happen, I'm sure.
And Node/Relationship/Path should all extend the same traversable interface then IMHO. But just to add these methods to TraversalDescription will in effect do the same thing up until the time where Neo4j is less ambivalent regarding traversal frameworks. 2011/8/2 Niels Hoogeveen <[email protected]> > > It looks like this does the same I suggested. It's a bit clunkier, but I > understand you don't want to changed the Node interface. OTOH is there any > reason not to extend the Node interface, after all it is only one "extends" > more? Since Nodes are all created in the neo4j-kernel component, there is no > real reason to maintain strict binary backwards compatibility between > versions, or do you expect people having projects with two separate > neo4j-kernel jars having different versions? > Niels > > > Date: Tue, 2 Aug 2011 23:05:17 +0200 > > From: [email protected] > > To: [email protected] > > Subject: Re: [Neo4j] Composable traversals > > > > Cool. To not mess around with interfaces too much I'm thinking of having: > > > > TraversalDescription#traverse( Node startNode, Node... > > additionalStartNodes ); > > TraversalDescription#traverse( Path startPath, Path... > > additionalStartPaths ); > > TraversalDescription#traverse( Iterable<Path> startPaths ); > > > > that would be rather similar, wouldn't it? > > > > 2011/7/30 Niels Hoogeveen <[email protected]> > > > > > > > > I would be all for it if this could become part of 1.5. > > > I am willing to put time into this. > > > > Date: Sat, 30 Jul 2011 11:33:01 +0200 > > > > From: [email protected] > > > > To: [email protected] > > > > Subject: Re: [Neo4j] Composable traversals > > > > > > > > Yes, FYI that's the exact thing we've been discussing :) > > > > > > > > 2011/7/29 Niels Hoogeveen <[email protected]> > > > > > > > > > > > > > > Great, I would much rather see this become part of the core API > than > > > have > > > > > this as part of the Enhanced API. > > > > > To make things work correctly, one important change to core is > needed: > > > The > > > > > Node interface needs to extends Traverser (the interface in > > > > > org.neo4j.graphdb.traversal, not the one in org.neo4j.graphdb). > > > > > This is actually not a big deal. There Traverser interface supports > > > three > > > > > methods: > > > > > Iterator<path> iterator() [return 1 path with 1 element in the > path, > > > being > > > > > the node itself]Iterable<Node> nodes() [return an iterable over the > > > node > > > > > itself]Iterable<Relationship> relationships() [return an empty > > > iterable] > > > > > With that addition, it's not all too difficult to enhance the > current > > > > > implementation of Traverser. It only adds one more iteration level > over > > > the > > > > > current implementation. Instead of having one start node, we now > have > > > > > multiple start paths. When returning values from the Traverser, the > > > start > > > > > paths and the result paths need to be concatenated. > > > > > In the new scenario, all "old" traverse() methods can remain the > same, > > > > > since Node becomes a Traverser, so those methods are just special > cases > > > > > where Iterable<Path> consists of 1 path, with just 1 element. > > > > > Niels > > > > > > Date: Fri, 29 Jul 2011 18:36:28 +0200 > > > > > > From: [email protected] > > > > > > To: [email protected] > > > > > > Subject: Re: [Neo4j] Composable traversals > > > > > > > > > > > > There have been thoughts a long while to make something like this > > > with > > > > > the > > > > > > traversal framework, but time has never been allocated to evolve > it. > > > I'm > > > > > > adding stuff to the framework in a side track and will surely add > > > some > > > > > > aspect of composable traversers also. > > > > > > > > > > > > 2011/7/29 Niels Hoogeveen <[email protected]> > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Mattias Persson, [[email protected]] > > > > > > Hacker, Neo Technology > > > > > > www.neotechnology.com > > > > > > _______________________________________________ > > > > > > Neo4j mailing list > > > > > > [email protected] > > > > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > > > > > _______________________________________________ > > > > > Neo4j mailing list > > > > > [email protected] > > > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > > > > > > > > > > > > > > > > -- > > > > Mattias Persson, [[email protected]] > > > > Hacker, Neo Technology > > > > www.neotechnology.com > > > > _______________________________________________ > > > > Neo4j mailing list > > > > [email protected] > > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > _______________________________________________ > > > Neo4j mailing list > > > [email protected] > > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > > > > > > -- > > Mattias Persson, [[email protected]] > > Hacker, Neo Technology > > www.neotechnology.com > > _______________________________________________ > > Neo4j mailing list > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [[email protected]] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
