Skip to content
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

add sort functionality to subjects and sort by id default #4359

Merged
merged 5 commits into from
Jul 17, 2024

Conversation

Tooyosi
Copy link
Contributor

@Tooyosi Tooyosi commented Jul 11, 2024

Implement sort functionality to subjects index controller and make sort by id default

Review checklist

  • First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
  • If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
  • If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
  • Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

@yuenmichelle1
Copy link
Collaborator

Apologies for the delay. I think defaulting sort by id this way is fine for now.

See benchmark comparison. (It looks like adding sort adds a bit of a difference in terms of latency, but not enough to discourage this idea. Using a subject set with 818884 subjects, running specific GET requests 1000 times. For me the "real" value is what I use for comparison. Real value is value in parens ).

                              user     system      total        real
page default without sort  0.084341   0.038063   0.122404 (238.689166)
page default with sort  0.083797   0.036512   0.120309 (276.923170)
page_size > than default of 20 without sort  0.094010   0.043372   0.137382 (248.150519)
page_size > than default of 20 with sort  0.088790   0.039840   0.128630 (292.650425)
start at different page without sort  0.078058   0.033642   0.111700 (221.236858)
start at different page with sort  0.079368   0.033695   0.113063 (270.571058)

Some things to note:

  • The first run of the query will always be slow and afterwards cached responses will be quick. Testing in production (without sort), the longest I've seen is ~23s wait for a response time, and after caching ~750 ms wait time)
    • I did get times when I get a QueryCancelled Timeout, but re-trying a request will get a result right afterward, so not too big of a concern.

@@ -13,6 +13,10 @@ class Api::V1::SubjectsController < Api::ApiController
before_action :check_subject_limit, only: :create

def index
unless params[:sort]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add a quick test for this change on the controller

Copy link
Collaborator

@yuenmichelle1 yuenmichelle1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick change: I would add a test to ensure params default is sort.

Later on, we can think about updating restpack_serializer to allow sorting defaults, so we don't have to manually set default sorting by setting params.

(My thought off the bat:
Maybe add a method
default_sort_by and an attr default_sorting_attribute to sortable.rb ,
then within #sorting_from_params options.rb method set sort_values to default_sorting_attribute.

Then in our serializers in panoptes, when we set can_sort_by we can also set default_sort_by. (Note this is me brainstorming, I have not tested this theory).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants