Our thoughts on how to handle pagination is "not yet", we'll get something
that works first, and then add pagination (in a number of places) later on.
As for sorting: yes, that is a comment on the API as a whole. We have opted
at not providing sorting, since there are good sorting facilities available
in the JRE already. Since that makes it easy for the user to implement their
own sorting it would be sub optimal for Neo4j to provide sorting. Since
sorting is a costly operation (both in time and space) it should be done as
late in the process as possible, probably with a lot of user code in between
the traversal and the place where the sorting actually takes place. This has
been our thinking in the REST API as well, meaning that sorting will be left
to the client. It is possible that we will return to this decision and add
sorting to the REST API, and that it might trickle down to the core API.
Features like this are however much easier to add than to remove, which is
why it is not implemented at the moment.
Cheers,
Tobias
On Wed, Apr 7, 2010 at 9:47 AM, Alastair James <al.ja...@gmail.com> wrote:
> >
> > > These two ways of traversing a graph complement each other, it's not
> that
> > > one is "better" than the other. Would you agree on this?
> >
>
> I think I agree. I would hope to be able to use XPath/Gremlin style
> querying
> for most things, and a more programatic system for more complex ones.
>
> > a JSON document describing the traverser, like:
> >
> > { "order": "depth first",
> > "uniquness": "node",
> > "return evaluator":
> > { "language": "javascript",
> > "body": "function shouldReturn( pos ) {...}" },
> > "prune evaluator":
> > { "language": "javascript",
> > "body": "function...." },
> > "relationships": [
> > { "direction": "outgoing",
> > "type": "KNOWS" },
> > { "type": "LOVES" }
> > ],
> > "max depth": 4 }
>
> Looks good for my needs. Using javascript in this form looks sensible.
>
> Any idea about the performance implications of using a javax.scripting
> language here? I guess not too severe.
>
> Is there any need for a shared context between calls to the evaluators? So
> I
> could store custom information and access it again when traversing further
> nodes. So, you could passing a 'context' object (with its initial values)
> that gets passed in as a second parameter to each evaluator function. Then
> again, this is probably bad practice....
>
> Any idea how you will handle pagination? Obviously sorting is an issue as
> you are unlikely to want the nodes in the traversal order. In my mind it
> would be nice to allow the return evaluator to return a 'sorting value'
> that
> indicates that nodes rank in the result set. E.g. sorting on a score
> attribute of the node:
>
> function shouldReturn(pos)
> {
> if (!some_condition) return false;
>
> return pos.currentNode().score;
> }
>
> But I guess this is a comment on the Neo API as a whole?
>
> Cheers
>
> Al
> _______________________________________________
> Neo mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
--
Tobias Ivarsson <tobias.ivars...@neotechnology.com>
Hacker, Neo Technology
www.neotechnology.com
Cellphone: +46 706 534857
_______________________________________________
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
