Re: [openstack-dev] [keystone] Pagination

Wed, 14 Aug 2013 10:08:36 -0700 

On 08/14/2013 12:25 PM, Mac Innes, Kiall wrote:

So, Are we saying that UIs built on OpenStack APIs shouldn't be able to
show traditional pagination controls? Or am I missing how this should
work with marker/limit?



No, not quite what I'm saying. The operation to get the total number of 
pages -- or more explicitly, the operation to get the *exact* number of 
pages in a list result -- is expensive, and in order to be reasonably 
efficient, some level of caching is almost always needed.



However, being able to page forwards and backwards is absolutely 
possible with limit/marker solutions. It simply requires the paging 
client (in this case, Horizon), to store the list of previously seen 
page links returned in listing results (there is a next and prev link in 
the returned list images results, for example).



e.g. for 11 pages of content, something like: 1 2 3 .. 10 11



Yeah, that's not an efficient operation unless you have some sort of 
caching in place. You can use things like MySQL's SQL_CALC_FOUND_ROWS, 
but that is not efficient since instead of stopping the query after 
LIMIT rows, you end up executing the entire query to determine the 
number of rows that *would* have been returned if no LIMIT was applied. 
In order to make such a thing efficient, you'd want to cache the value 
of SQL_CALC_FOUND_ROWS in the session and use that to calculate the 
number of pages.



It's something that can be done, but isn't, IMHO, worth it to get the 
traditional UI you describe. Instead, a good filter/search UI would be 
better, with just next/prev links.


Best,
-jay


Thanks,
Kiall

On 13/08/13 22:45, Jay Pipes wrote:

On 08/13/2013 05:04 PM, Gabriel Hurley wrote:

I have been one of the earliest, loudest, and most consistent PITA's about 
pagination, so I probably oughta speak up. I would like to state three facts:

1. Marker + limit (e.g. forward-only) pagination is horrific for building a 
user interface.
2. Pagination doesn't scale.
3. OpenStack's APIs have historically had useless filtering capabilities.

In a world where pagination is a "must-have" feature we need to have page 
number + limit pagination in order to build a reasonable UI. Ironically though, I'm in 
favor of ditching pagination altogether. It's the lowest-common denominator, used because 
we as a community haven't buckled down and built meaningful ways for our users to get to 
the data they really want.

Filtering is great, but it's only 1/3 of the solution. Let me break it down with problems 
and high level "solutions":

Problem 1: I know what I want and I need to find it.
Solution: filtering/search systems.


This is a good place to start. Glance has excellent filtering/search
capabilities -- built in to the API from early on in the Essex
timeframe, and only expanded over the last few releases.

Pagination solutions should build on a solid filtering/search
functionality in the API, where there is a consistent sort key and
direction (either hard-coded or user-determined, doesn't matter).

Limit/offset pagination solutions (forward and backwards paging, random
skip-to-a-page) are inefficient from a SQL query perspective and should
be a last resort, IMO, compared to limit/marker. With some smart
session-storage of a page's markers, backwards paging with limit/marker
APIs is certainly possible -- just store the previous page's marker.


Problem 2: I don't know what I want, and it may or may not exist.
Solution: tailored discovery mechanisms.


This should not be a use case that we spend much time on. Frankly, this
use case can be summarized as "the window shopper scenario". Providing a
quality search/filtering mechanism, including the *API* itself providing
REST-ful discovery of the filters and search criteria the API supports,
is way more important...


Problem 3: I need to know something about *all* the data in my system.
Solution: reporting systems.


Sure, no disagreement there.


We've got the better part of none of that.


I disagree. Some of the APIs have support for a good bit of
search/filtering. We just need to bring all the projects up to search
speed, Captain.

Best,
-jay

p.s. I very often go to the second and third pages of Google searches.
:) But I never skip to the 127th page of results.

   > But I'd like to solve these issues. I have lots of thoughts on all of
those, and I think the UX and design communities can offer a lot in
terms of the usability of the solutions we come up with. Even more, I
think this would be an awesome working group session at the next summit
to talk about nothing other than "how can we get rid of pagination?"


As a parting thought, what percentage of the time do you click to the second 
page of results in Google?

All the best,

       - Gabriel


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev























					Reply via email to