Open Stack

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.

> 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?

> @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.

Best,
-jay