Skip to content

Conversation

@jnation3406
Copy link
Member

…ries too

This addresses the bug in /versions/ queries, but also adds in exact counts for /thumbnails/ queries if any of its indexed fields are used.

@jnation3406 jnation3406 requested a review from jashan-lco August 19, 2025 23:27
Copy link
Contributor

@jashan-lco jashan-lco left a comment

Choose a reason for hiding this comment

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

Makes sense, but I really wish DRF provided a easy way to set pagination classes per view to separate things out a bit

self.small_query = True
elif 'request_id' in query_params or 'observation_id' in query_params:
# /versions/?md5= queries need the accurate count for shipping data in
elif request.path == '/versions/' and 'md5' in query_params:
Copy link
Contributor

Choose a reason for hiding this comment

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

Stupid Django question...but is the path normalized? Like if they go to /versions?limit=1 does that always redirect to /versions/?limit=1

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah it seems to get http 301'ed to the /versions/?limit=1 if you do the first

self.small_query = True
# Or up to 2 months of querys with some other bounding params
elif timespan <= timedelta(weeks=9) and any(field in query_params for field in ['proposal_id', 'target_name_exact']):
self.small_query = True
Copy link
Contributor

Choose a reason for hiding this comment

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

imo, an explicit terminal else clause makes it easier for my brain to process if/else branches...especially nested ones

@jnation3406
Copy link
Member Author

Makes sense, but I really wish DRF provided a easy way to set pagination classes per view to separate things out a bit

It does provide an easy way to separate pagination class per view - you can just set it on the view itself and it overrides the default setting in settings.py. Do you think that would be better? I figured there would be mostly overlap besides that if/else block but I'm happy to pull it out into separate pagination classes if you think that is better.

@jnation3406 jnation3406 requested a review from jashan-lco August 25, 2025 16:51
@jashan-lco
Copy link
Contributor

Makes sense, but I really wish DRF provided a easy way to set pagination classes per view to separate things out a bit

It does provide an easy way to separate pagination class per view - you can just set it on the view itself and it overrides the default setting in settings.py. Do you think that would be better? I figured there would be mostly overlap besides that if/else block but I'm happy to pull it out into separate pagination classes if you think that is better.

Oh, really? Couldn't figure that out from the docs. IMO it might make things a bit more maintainable going forward and you'll get rid of the outer if/else branches.

@jnation3406
Copy link
Member Author

Makes sense, but I really wish DRF provided a easy way to set pagination classes per view to separate things out a bit

It does provide an easy way to separate pagination class per view - you can just set it on the view itself and it overrides the default setting in settings.py. Do you think that would be better? I figured there would be mostly overlap besides that if/else block but I'm happy to pull it out into separate pagination classes if you think that is better.

Oh, really? Couldn't figure that out from the docs. IMO it might make things a bit more maintainable going forward and you'll get rid of the outer if/else branches.

I fully implemented it as separate pagination classes, but then realized the viewset mixer allowing limitoffset vs. cursor would be broken if we wanted to use it on the other endpoints later, which we might. So I think I vote to just keep it as-is for now.

@jnation3406 jnation3406 merged commit a350edb into main Sep 11, 2025
12 checks passed
@jnation3406 jnation3406 deleted the fix/count_params branch September 11, 2025 18:29
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.

3 participants