Tobias Ivarsson schrieb am 08.04.2010 um 18:23:27 (+0200) [Re: [Neo] Traversers in the REST API]:
> On Wed, Apr 7, 2010 at 3:05 PM, Alastair James <al.ja...@gmail.com> > wrote: > > 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. > > For paging / limiting: yes, you are absolutely right, this would not > effect the core API at all, only the REST API. Limiting/paging is > something we would probably add to the REST API before sorting. Limiting and paging usually go hand in hand with sorting, in my experience. Why would anyone want to page through an unsorted collection? > Sorting might be a similar case, but I still think the client would be > better fitted to do sorting well. The server has indexes to support the sorting. (If it doesn't, it has a problem anyway.) What does the client have to support sorting? So how would it be better fitted to do sorting well? > But once paging / limiting is added it would be quite natural / useful > to add sorting as well. What I want to avoid is keeping state on the > server while waiting for the client to request the next page. If you ensure a binary tree index is used to do the sorting, you should be fine. -- Michael Ludwig _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
