On 04/09/17 11:17 AM, Mikhail Kebich wrote: > Hello Gordon, > > Any feedback? Did you get a chance to take a look at the cursor api prototype? > > Thanks, > Mike > > On Wed, Aug 30, 2017 at 6:00 PM, Mikhail Kebich > <[email protected]> wrote: >> On Wed, Aug 30, 2017 at 4:22 PM, gordon chung <[email protected]> wrote: >>> ah, i see. iirc, we can choose what we sort on. can this be solved by >>> just passing in a different sort key? or maybe we need to support >>> returning results without sort. >> >> I thought about this. The key issue I see here is that the api does >> not include "id" sort key to the result. Because of this api clients >> can't specify a value of marker that points to the next batch of >> events. And I believe we should think carefully about exposing this >> filed because it may be meaningless depending on a storage back-end. >> >> Actually, cursors are intended to solve this issue by specifying a >> value of marker explicitly without making an assumption what marker >> is. >> >> I attached a prototype. It is based on stable/ocata branch. I did not >> replace existing pagination and just provided another URL route to use >> cursors. But, I think it is possible to replace current pagination >> logic with cursors, because if a storage back-end understands markers >> it can specify the value explicitly. >>
sorry, i thought you were going to post your patch to gerrit. i just took a look at your patch. you can correct me if i misunderstand your patch but it just seems that you want to add support to use id as a marker, specifically the following: + marker = models.Event(None, None, None, None) + marker.id = cursor + sort_keys = ['id'] + sort_dirs = ['asc'] + query = oslo_sql_utils.paginate_query( + query, models.Event, limit, sort_keys, + sort_dirs=sort_dirs, marker=marker) the one concern i have with raising id is because its just an autoincremented number (i believe) and it has no meaning outside of the db. i also don't believe it exists in any of the other backends. based on the code above, i would imagine the equivalent could be achieved by just sorting by id and continuing to use message_id as a marker. (sorting by id might not be necessary but sql apparently doesn't guarantee default order) cheers, -- gord __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
