Bug #13763

[API] groups#contents response should obey caller-provided order (not sort on type first)

Added by Tom Clegg 5 months ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
API
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Story points:
-

Description

Currently if a groups#contents request specifies order=[name], the response will be ordered

type=group              name=foo1
type=group              name=foo3
type=collection         name=foo2
type=collection         name=foo4
type=container_request  name=(null)

The response should be ordered

type=group              name=foo1
type=collection         name=foo2
type=group              name=foo3
type=collection         name=foo4
type=container_request  name=(null)
Nonexistent columns should be sorted as "greater than null". For example, with order=["groups.group_class", "users.first_name desc", "uuid"], the order of returned items should be
  1. groups with non-null group_class (sorted by group_class)
  2. groups with null group_class (sorted by uuid)
  3. users with null first_name (sorted by uuid)
  4. users with non-null first_name (sorted by descending first_name)
  5. container requests (sorted by uuid)

History

#1 Updated by Tom Clegg 5 months ago

  • Description updated (diff)

#2 Updated by Tom Clegg 5 months ago

  • Description updated (diff)

Suggest using a UNION query to get the desired set of UUIDs, then fetch the records as AR objects to return.

#3 Updated by Tom Clegg 5 months ago

When order=["name"], rows from tables without a name column should be sorted as if they had a null in the name column.

TBD: Should we support the "groups.name" notation? Choices:
  1. Return an error.
  2. Return groups first (non-null names first, then null names), then non-group items.
  3. Sort non-group items alongside the groups with null names. IOW, return groups with non-null names first, then fall back on subsequent/implicit/default orders for other object types and the remaining groups. (seems most intuitive)

The existing API ignores orders that are not prefixed by a table name.

However, the existing API accepts filters for both "groups.group_class" (meaning the filter does not affect types other than group) and "group_class" (meaning the filter applies to all types, and constitutes an error if a table is missing that column and is not excluded via "is_a" filter).

It might be less confusing if we also update the filtering behavior to match the new ordering behavior for unprefixed columns: i.e., for purposes of filtering, a nonexistent column is null.

#5 Updated by Tom Morris 5 months ago

  • Target version set to To Be Groomed

Also available in: Atom PDF