Cheers guys. All sounds good. One comment:
> 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. > Well, thats the case when Neo is running in the same JVM as the user code, but when we start talking about returning 1000s of nodes in JSON over HTTP just to get the first 10 this is clearly sub-optimal (as I build websites this is a very common use case). So, as you say, sorting and limiting can wait, but I suspect the HTTP API would benefit from offering it. Limiting need not require changes to the core API, it could be implemented as a second stage in the HTTP API code prior to output encoding. Cheers Al _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
