-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Issue #1467] Add order_by support for more fields #1481
Conversation
…4-update-api-schema
…4-update-api-schema
…4-update-api-schema
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me!
# means we can't determine how to sort / need to correct | ||
# the mismatch. | ||
msg = f"Unconfigured sort_by parameter {pagination.order_by} provided, cannot determine how to sort." | ||
raise Exception(msg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like is should raise a HTTP 400, not a HTTP 500? Do you have a class for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to return a 500 here, if this happens, it is because of a bug in our code. This means our API allows you to pass in a field to sort by that we haven't implemented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
# This determines whether we use ascending or descending when building the query | ||
sort_fn = asc if pagination.is_ascending else desc | ||
|
||
match pagination.order_by: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat to see match
being used, I haven't used it yet.
Summary
Fixes #1467
Time to review: 10 mins
Changes proposed
Added the ability to order_by several more fields
Updates to test structure, continuing a pattern from the parent PR
Context for reviewers
Except for relevancy (which is its own separate ticket if we do it prior to a search index), this should cover all the sorting needs for search in the near term.
One callout is that sorting always shoves null values to the end now, regardless of whether they are ascending or descending (by default, Postgres considers null to be the largest value).
Additional information
Did some local testing of performance with the queries we actually use, and sorting by any of these fields has effectively the same performance cost, and adding an index to the un-indexed ones didn't seem to change that.