[Standards-JIG] JEP-0059: Result Set Manipulation
erkyrath at eblong.com
Thu Jan 19 04:16:09 UTC 2006
Having not looked at JEPs recently, I dive back into the stack of
The theory is to "Page through a result set by retrieving the items in
smaller subsets." However, the proposed mechanism is hard to use. If I
start fetching pages of a result set, I have no way to tell if the result
set changes out from under me. (Say, if the underlying results change
between the time I fetch page 2 and page 3.) Depending on the server's
ordering, I may miss some results, see others twice, or both.
The usual fix for this sort of thing is to include an identifier in the
server's result. This stays the same for as long as the server's
underlying data stays the same. (It could be a timestamp of the most
recent data change, or just an incrementing integer.) Each time the client
fetches a page (after the first), it can compare the identifier with the
one from the previous page. If they don't match, the client can either
declare the paged-get to be a failure or start over, whichever it likes.
(Of course, if the client starts over, but the server's data is churning
continuously, the client might *keep* starting over. And never
actually finish fetching pages, I mean. I don't see any way around that;
the client just has to be written to give up after three restarts or some
I guess it's valuable to have this identifier in <count> requests also.
Also, typo: the line before example 8 is:
> The responding entity then returns the first page of the result set:
...which should say "second page".
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
Making a saint out of Reagan is sad. Making an idol out of Nixon ("If the
President does it then it's legal") is contemptible.
More information about the Standards