Open Stack

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
> <mikhail.kebich at gmail.com> wrote:
>> On Wed, Aug 30, 2017 at 4:22 PM, gordon chung <gord at live.ca> 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