[openstack-dev] [Ceilometer][Horizon] The future or pagination

John Dickinson me at not.mn
Wed Nov 13 20:24:58 UTC 2013

marker + end_marker, such that the result is in [marker, end_marker), and a reverse parameter allows you to build your UI with next and prev links.

Also, limit+offset has the distinct disadvantage to skipping or repeating entries while going to the next or previous page if the listing is being changed while it is being paginated.


On Nov 13, 2013, at 9:51 AM, Lyle, David <david.lyle at hp.com> wrote:

> From a purely UI perspective, the limit/offset is a lot more useful.  Then we can show links to previous page, next page and display the current page number.
> Past mailing list conversations have indicated that limit/offset can be less efficient on the server side.  The marker/limit approach works for paginating UI side, just in a more primitive way.  With that approach, we are generally limited to a next page link only.
> David 
>> -----Original Message-----
>> From: John Dickinson [mailto:me at not.mn]
>> Sent: Wednesday, November 13, 2013 10:09 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Ceilometer][Horizon] The future or
>> pagination
>> Swift uses marker+limit for pagination when listing containers or objects
>> (with additional support for prefix, delimiters, and end markers). This is
>> done because the total size of the listing may be rather large, and going to a
>> correct "page" based on an offset gets expensive and doesn't allow for
>> repeatable queries.
>> Pagination implies some sort of ordering, and I'm guessing
>> (assuming+hoping) that your listings are based around something more
>> meaningful that an incrementing id. By itself, "metric number 32592"
>> doesn't mean anything, and listings like "go to metric 42000000 and give me
>> the next 768 items" doesn't tell the consumer anything and probably isn't
>> even a very repeatable query. Therefore, using a marker+prefix+limit style
>> pagination system is very useful (eg "give me up to 1000 metrics that start
>> with 'nova/instance_id/42/'"). Also, end_marker queries are very nice (half-
>> closed ranges).
>> One thing I would suggest (and I hope we change in Swift whenever we
>> update the API version) is that you don't promise to return the full page in a
>> response. Instead, you should return a "no matches" or "end of listing"
>> token. This allows you the flexibility to return responses quickly without
>> consuming too many resources on the server side. Clients can then continue
>> to iterate over subsequent pages as they are needed.
>> Something else that I'd like to see in Swift (it was almost added once) is the
>> ability to reverse the order of the listings so you can iterate backwards over
>> pages.
>> --John
>> On Nov 13, 2013, at 2:58 AM, Julien Danjou <julien at danjou.info> wrote:
>>> Hi,
>>> We've been discussing and working for a while on support for
>>> pagination on our API v2 in Ceilometer. There's a large amount that
>>> already been done, but that is now stalled because we are not sure
>>> about the consensus.
>>> There's mainly two approaches around pagination as far as I know, one
>>> being using limit/offset and the other one being marker based. As of
>>> today, we have no clue of which one we should pick, in the case we
>>> would have a technical choice doable between these two.
>>> I've added the Horizon tag in the subject because I think it may
>>> concern Horizon, since it shall be someday in the future one of the
>>> main consumer of the Ceilometer API.
>>> I'd be also happy to learn what other projects do in this regard, and
>>> what has been said and discussed during the summit.
>>> To a certain extend, we Ceilometer would also be happy to find common
>>> technical ground on this to some extend so _maybe_ we can generalise
>>> this into WSME itself for consumption from other projects.
>>> Cheers,
>>> --
>>> Julien Danjou
>>> ;; Free Software hacker ; independent consultant ;;
>>> http://julien.danjou.info
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/253063bf/attachment.pgp>

More information about the OpenStack-dev mailing list