Open Stack

On 09/05/2017 08:44 AM, gordon chung wrote:
> 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.

Correct.

> 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)

Why not sort by created date/timestamp? Wouldn't that give you the same 
behaviour (for the most part).

Best,
-jay