Sure but isn’t it a huge waste of bandwidth if you load hundreds of results and the user only looks at the first dozen?
On Thu, Jul 28, 2011 at 15:16, Rick Bullotta <rick.bullo...@thingworx.com>wrote: > BTW, "paging" is a relic of the dial-up modem days, IMNSHO. > > If a machine is the client of the REST API call, it should get all the data > in a single, atomic call. If it is a browser or mobile app, there's a > natural limit to the # of items that a human will bother paging through, > which is fairly small (20 -> 500 typically), so again, it is painless to get > all the data in a single call. > > -----Original Message----- > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] > On Behalf Of Rick Bullotta > Sent: Thursday, July 28, 2011 6:11 PM > To: Neo4j user discussions > Subject: Re: [Neo4j] Paged traversal REST API suggestion for improvement > > If you don't keep "state" paging will not work properly if the data changes > often. What may have been record #21 when you are viewing the first page of > 20 result might not be record #21 when you go to fetch the 2nd "page". > > If you're only concerned with pages of 20 or so, you should absolutely, > positively do the paging on the browser. Anything up to a couple thousand > rows can *easily* be handled by any modern browser. Keep the parsed JSON > data on the client side and page it there. This approach will be very > performant on both the client and server, and won't require any "state". > > -----Original Message----- > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] > On Behalf Of Aseem Kishore > Sent: Thursday, July 28, 2011 3:01 PM > To: Neo4j user discussions > Subject: Re: [Neo4j] Paged traversal REST API suggestion for improvement > > 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 > _______________________________________________ > 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 > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
