[API] groups#contents response should obey caller-provided order (not sort on type first)
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
- groups with non-null group_class (sorted by group_class)
- groups with null group_class (sorted by uuid)
- users with null first_name (sorted by uuid)
- users with non-null first_name (sorted by descending first_name)
- container requests (sorted by uuid)
#3 Updated by Tom Clegg over 3 years ago
order=["name"], rows from tables without a name column should be sorted as if they had a null in the name column.
- Return an error.
- Return groups first (non-null names first, then null names), then non-group items.
- 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.