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 <[email protected]> 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. _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
