Open Stack

Excerpts from Jay Pipes's message of 2014-11-19 19:35:18 -0800:
> On 11/19/2014 09:49 PM, Robert Collins wrote:
> > On 20 November 2014 13:43, Jay Pipes <jaypipes at gmail.com> wrote:
> >> On 11/19/2014 07:32 PM, Michael Krotscheck wrote:
> >>>
> >>> Jay-
> >>>
> >>> My own UX tests have demonstrated a need for both page jumping, and
> >>> being able to communicate to a user where they are in their list. I'd be
> >>> happy to show you the videos if you have a few hours.
> >>
> >>
> >> I don't have a few hours, no. :) But, what use case does jumping to page 7
> >> of some results listing fulfill?
> >
> > For one, remembering where you were and coming back to it (more or less).
> 
> Sorry, I don't get this at all. I have never, once, wanted to coming 
> back to some random page of results. I often want to come back to a 
> specific record, but that's not what we're talking about here.
> 
> I can think of no time in my life that I've thought to myself "Oh, you 
> know, I really should go back to page 17 of my Google search results for 
> 'frobnozzle'". It just isn't a valid use case, IME.
> 

"I saw a bug about that, can't remember the title exactly but it was
around page 17."

> > Jumping by batch index is cheap compared to the proposed
> > clone-the-result-set-ids thing, and IME useful enough that I'd be
> > annoyed at a system without it.
> 
> What does "jump to page 17" give you -- usefulness-wise -- over seeing 
> that there is a) X number of results in total and/or b) there are more 
> results to page through?
> 

Human brains don't all work the same. Perhaps there are quite a few
people who jump to specific pages.

> > @Michael - I suggest just using a simple stable batch marker - e.g.
> > the unique key of the edge of the batch - which is stable enough to
> > handle inserts and deletes without double-showing or skipping rows.
> 
> That's what already exists in olso.db.utils.paginate_query(). The marker 
> is the unique key of the edge of the batch.
> 

Pretty sure one could count the batches one time and assign page numbers
to them as they're seen in a cache, rather than materializing a whole
result set.