On Tue, Jun 28, 2016, at 02:09 PM, Matt Riedemann wrote: > On 6/27/2016 9:57 PM, Alex Xu wrote: > > Matt, thanks for the email, I +1 on the next page link. Then user > > needn't build up link by themself. > > > > I also have one more question after review those pagination patches: > > > > As those pagination proposes change the default sort order. So should we > > keep the sort order for old version API? > > I think it should be yes. For instance-actions, it should keep the > > order sorted by 'create_at' column in old versionAPI. The new version > > API will sort the result by 'updated_at' column. > > This sounds reasonable since we were already ordering on created_at for > instance actions: > > https://github.com/openstack/nova/blob/0c5ff5057edcf1f9ab55a559804a5c0c6a8158b2/nova/db/sqlalchemy/api.py#L5976 > > > But the question for keypairs and hypervisors, looks like they > > didn't specify the sort order explicitly, so I think they should depend > > on the DB implementation. Should we keep the old version API unspecified > > sort order? > > I think Andrew Laski made a comment about this in the keypairs change > also, that since we never explicitly guaranteed a sort order for these > before and never documented anything to that effect, enforcing a new > sort order should not be a problem, regardless of the microversion. The > natural sort order should be the auto-incrementing id but that's not > guaranteed. And the hypervisors pagination change is using id for > sorting. The keypairs change is sorting by name. I think at the summit > we even told Pavel to push a separate change before the microversion to > start ordering keypairs since we weren't going to support sort keys. > > So I don't have a strong opinion either way. If it's just a difference > in which DB API method gets called per the microversion, that seems > simple enough to keep it working as it did before the pagination changes > are added. If it makes the code much more complicated though, then I'd > probably not try to retrofit the ordering, or lack thereof.
I think the most important thing is some sort of generally stable ordering so two requests with no intervening change return the same ordering. But I also don't view it as a contract that we have to ensure through a change, either a microversion or a data migration. If we're stable before the change and stable afterwards then some temporary instability should be okay as long as we return the correct data. If users need a completely predictable sort order then we need to offer a sort_key parameter. Though I'm not suggesting we do that. > > -- > > Thanks, > > Matt Riedemann > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
