fix(backend): the export reads a campaign's rows by join, not by a list of ids (#1113) #1120
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/1113-export-bind-lists"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #1113. Held for 4.5.1: do not merge before v4.5.0 is tagged. The export is not something to change in the last hours before a prod release, and nothing real is near the limit.
Every
IN (...)list on the export path that carried one bind per parent row is now a join or subquery scoped to the campaign, with the filter the list encoded (live plus binned pages without bot proposals, live threads, active sheets, the campaign's atlases). Sites:routers/campaigns.py::export_campaignandquest_archive,sheet_archive,files_archive,prep_shelf_archive,discussion_archive,atlas_archive,party_archive.rules_archivealready chunks at 500 and is unchanged.tests/export/test_export_bind_lists.pyexports a campaign of 300 pages, posts and markers and 60 sessions and asserts no statement carries more than 200 binds. On main it fails (map_links ... IN, 600 binds).Run before this PR: 1,897 backend tests around export, discussions, sheets, parties, maps and campaigns, including the round-trip and golden export tests; ruff check. Not re-run:
ruff format --checkafter the last reformat.To look at before merging: queries that had no
ORDER BY(notes, attendance, aliases, owners, appearances) now return in the join's order instead of the IN scan's. Both are undefined and the tests pass, but an export's row order is not provably identical on a real database. Consider adding anORDER BYto each.🤖 Generated with Claude Code