Show recently updated capture sets first in pickers, and stop them waiting on counts they never show - #1381
Draft
mihow wants to merge 2 commits into
Draft
Show recently updated capture sets first in pickers, and stop them waiting on counts they never show#1381mihow wants to merge 2 commits into
mihow wants to merge 2 commits into
Conversation
The capture set list endpoint reports the number of captures, occurrences and taxa in each set. Filters and pickers only need to name a set, so serving their options from that endpoint made every dropdown wait on counts nobody reads. /api/v2/captures/collections/choices/ returns the id, name and sampling method of each capture set in a project, following the same pattern as the occurrence algorithm filter's choices at /occurrences/algorithms/. The list endpoint keeps its counts. The viewset also gains a default ordering of most recently updated first. It had none, so row order came back in whatever order Postgres produced, which left pagination unstable and could put a capture set a user had just created outside the first page of a picker. Co-Authored-By: Claude <noreply@anthropic.com>
The job form, the export form and the capture set filter now read their options from /captures/collections/choices/, so they no longer wait on counts they do not display, and the most recently updated capture sets come first. The job and export picker still shows how many captures the selected set holds. That count now comes from a single-record fetch of the selected set, the same shape the taxon filter uses for its selected taxon. A set that was picked before it fell off the end of the list is added back to the options, so an existing selection never disappears from the form. Co-Authored-By: Claude <noreply@anthropic.com>
✅ Deploy Preview for antenna-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for antenna-ssec ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Picking a capture set when starting a job is meant to be the easy part of the form, and
in a project that has accumulated a lot of capture sets it currently is not. The dropdown
loads one page of results in whatever order the database happens to return them, so a set
a user created minutes ago may not be in the list at all, and there is no way to reach it
from the form. The same dropdown also waits on the number of captures, occurrences and
taxa in every capture set in the project — figures it never displays — which is why it
sits disabled for a long time before it becomes usable.
This changes both. Capture sets now come back most recently updated first, so the sets
someone is actively working with are at the top of every picker and filter. And the
pickers read from a new endpoint that returns just enough to name a capture set, so they
no longer pay for counts they do not show. The endpoint follows the pattern introduced
for the occurrence algorithm filter in #1368: a small, purpose-built sub-action that
serves a filter's choices, separate from the full list endpoint the table page uses.
Reported against a project whose capture set list had grown past one page.
List of Changes
ordering = ["-updated_at"]onSourceImageCollectionViewSet. The capture sets table page asks for its own sort order and is unaffectedGET /api/v2/captures/collections/choices/returning id, name and sampling method per set, serialized with the existingSourceImageCollectionNestedSerializer.CaptureSetPickerandCaptureSetFilterread from ituseCaptureSetDetailsfetches the selected set on its own, the same shape the taxon filter uses for its selected taxonDetailed Description
The capture set list endpoint annotates three counts on every row —
source_images_count,source_images_with_detections_countandsource_images_processed_count— each of which joins through captures to detections andde-duplicates. Grouping happens before
LIMIT, so asking for 20 rows still costs thewhole project. Two measurements from a local copy of production data, on a project with
46 capture sets:
list(qs[:20])with no count annotationslist(qs[:20])with the three count annotationsEnd to end over HTTP on the same machine, the list endpoint took 51.8s cold against 1.8s
for the new choices endpoint. Both numbers include local development middleware, so treat
them as indicative of the gap rather than as production figures; the ORM timings above are
the direct measurement.
The counts themselves are untouched — the capture sets table still reports all of them,
and
?with_counts=truestill adds occurrence and taxa counts. The annotations simplymoved from the viewset's class-level queryset into
get_queryset()so the choices actioncan opt out of them. Sorting by a count is still available on the list endpoint and is
excluded from the choices action, where the annotations do not exist.
Testing
ami.main.testsandami.exports: 322 tests, all passing.TestCaptureSetChoices(8 tests) pins the contract the pickers depend on: mostrecently updated first, names without counts, scoped to the requested project, a
project is required, capture sets in a draft project stay hidden from non-members, and
the list endpoint keeps both its counts and its ability to sort by them.
tsc --noEmit,eslintandprettier --checkall clean.makemigrations --checkpasses.What has not been verified
The change has not been clicked through in a browser. The local
uicontainer serves apre-built bundle rather than a dev server, and the host dev server would not start against
this checkout. The requests the pickers make were exercised directly instead, against a
local copy of production data:
GET /captures/collections/choices/?project_id=…&limit=200&offset=0→ 46 of 46 sets,most recently updated first, no count fields.
GET /captures/collections/{id}/?project_id=…&with_counts=false→ the selected setwith
source_images_countpopulated, in 0.3s.Worth a click-through on the job form and the occurrences page filter before merge.
Follow-up
#1380 proposes replacing the dropdown with a searchable field like the taxon filter, which
is the real fix for a project with more capture sets than one page can hold. This change
makes the common case work; it does not make an arbitrarily long list navigable.