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.keb...@gmail.com> wrote:
On Wed, Aug 30, 2017 at 4:22 PM, gordon chung <g...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
