On 15/08/2013, at 3:02 AM, Jay Pipes <jaypi...@gmail.com> wrote: > 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).
Is there a prev link? It's optional in Compute v2 and Images v1 and Nova/Glance don't seem to be returning it. I suspect Nova v3 isn't either but I haven't tested it. There's no mention of it in Images v2 at all and no prev returned there either. If there is a next and prev link in the returned results then Horizon wouldn't need to store anything - the links can be rendered straight into the page. Anyway, you're right, this is all secondary to the need for decent filtering. > >> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev