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 db] <---- [web server] <---- [web client, e.g. browser] If I want to show the results of a search, let's say, in a way that supports paging, it just seems like I can't take advantage of the Neo4j API at all here. If the user wants to be able to refresh the page, or click "Prev", the browser isn't keeping state across page changes, so it has to rely on the web server to give it the right page. If the server now has to keep state of all results, it defeats the purpose of using the Neo4j paging API altogether: the server necessarily has to fetch everything and handle paging itself. Am I missing something? Or is this (typical in our case) scenario not something you guys are designing for? (And if not, what *is* the use case you guys envisioned for this?) It seems to me that the root cause of this dilemma is the Iterable<T> constraint you mentioned -- it only goes forward. 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). E.g. the following requests: - "Get me the results of this traverse" would return everything - "Get me the results of this traverse, paged with size 20" would return 20 results - "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 - etc. Aseem On Thu, Jul 28, 2011 at 5:09 AM, Jim Webber <j...@neotechnology.com> wrote: > Hi Aseem, > > When you GET a resource, you're asking for its state at a particular > instant in time. GET's don't always return the same content, what's > important about them is that clients can't be held responsible for any > (unintended) side-effects of a GET operation. For example, if you GET the > BBC new page now, and then GET it again in 20 minutes, the bytes you receive > will almost certainly be different. > > I think what's perhaps a bit odd in the paged traverser case is that > clients do in fact trigger a state transition on GET which materially > changes the response. Adding /next to the paged traverser URI does not > change this, it just lengthens the URI. > > Under the covers, the REST API is just using the traversal API and so gets > back an Iterable<T> which is forward-only. We can't (or rather won't) do > things like ?page=2 (or similar) because that would involve holding all the > traversal state on the server which is one of the things paged traversers > were meant to avoid (being kind to both the server and clients). > > If you want to remember all traversal state on the client, that's OK. You > can page through your own local data structures. In fact given the number of > clients is likely to be larger than the number of servers, this makes sense > since the memory burden is shared amongst the many clients, rather than > being placed on the single server. > > So, I'll buy that we've conflated a little too much into a single GET, but > it's motivated by a sincere trade off to not overburden the server. > > Jim > > > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
