Hi Aseem, > Jim, thanks for the explanation. I understand your constraints, but thinking > about it more, I'm actually even more baffled -- how can we actually make > use of this paged traversal API in a web scenario?
Neo4j's traversers (which is what the REST paging API really is) knows nothing about the back button. It is simply a way of getting bite sized chunks of results back to the client while minimising client, server, and network overhead. It's more discrete streaming than a hypermedia set of pages. If your client wants to provide navigation, then it can. But it is your client's job to cache previous pages that it's pulled from the server. The server does not support prev navigation because the aggregate costs to the server are prohibitive. [snip] > It seems to me that the root cause of this dilemma is the Iterable<T> > constraint you mentioned -- it only goes forward. Yes it does, and for good performance reasons. > Perhaps a better API/model then would be to use an offset parameter. This is > different than "page" because it doesn't require the server to keep state; > it just tells the server, return me the results starting *after* this result > (which would generally be the last result I saw on my previous page of > results). The offset would require us to go forward through the iterator to the offset. Then return from there. I'd considered it briefly, but then dropped the idea since it's extremely wasteful. > - "Get me the results of this traverse" would return everything That's what the normal (non-paged) traversal API does. > - "Get me the results of this traverse, paged with size 20" would return 20 > results That's what the paged traversal API does. > - "Get me the results of this traverse, paged with size 20, starting with > the node/rel after this one [given by an ID]" would return the next 20 > results That's what (sort of) repeated GETs on the traversal API does, with the caveat that you already specified the page size when you set up the traverser. But we can't give you the ability to look up an arbitrary page on the server. That doesn't even make sense since between invocations the graph may mutate and you'll get different results back anyway. Jim PS - if you want to be prev friendly, then think about making the entire prev page cacheable rather than placing another call on the server for the previous page and doing the hard work of rendering it all over again. _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
