Search index: replace ComicFTS bulk_update with delete+bulk_create

[ajslater]

Summary

Swap ComicFTS.objects.bulk_update(...) for delete + bulk_create (wrapped in transaction.atomic) at the two production update sites. FTS5 makes bulk_update expensive in two stacked ways:

1. SQLite's CASE WHEN id THEN val … parser cost grows in (rows × cols).
2. Every UPDATE on an FTS5 virtual table is internally a delete-then-reinsert at the segment level anyway, so the CASE WHEN overhead is purely waste.

A multi-row INSERT is parsed once and writes straight to the segment.

Benchmarks

tests/perf/bench_fts_sync.py — synthetic seeded snapshot, 5 runs per combo, median ms.

Synthetic (1k / 10k tables)

Table	Affected	Fields	A bulk_update	B delete+create	B vs A
1,000	1,000	1	199ms	105ms	1.9×
1,000	1,000	3	361ms	104ms	3.5×
10,000	1,000	1	207ms	135ms	1.5×
10,000	1,000	3	371ms	125ms	3.0×
10,000	10,000	1	1,929ms	1,038ms	1.9×
10,000	10,000	3	3,290ms	991ms	3.3×

Real DB (Milliways, 10,036 ComicFTS rows)

Affected	Fields	A bulk_update	B delete+create	B vs A
100	1	33ms	29ms	1.1×
100	3	46ms	29ms	1.6×
1,000	1	219ms	193ms	1.1×
1,000	3	381ms	184ms	2.1×
5,000	1	1,013ms	854ms	1.2×
5,000	3	1,726ms	863ms	2.0×

Pattern holds across both: B wins every combo, gap widens with field count. The real-DB win is more modest at 1 field (~10–20%) but doubles at 3 fields, and the m2m sync case routinely touches multiple fields per affected comic.

Changes

• SearchIndexSyncManyToManyImporter.sync_fts_for_m2m_updates — restructured so each affected comic is fetched exactly once even when several m2m fields changed for it. The previous loop appended one ComicFTS instance per (comic, field) pair, which bulk_update then resolved unpredictably when duplicate pks landed in the same call. New _gather_m2m_field_values collapses to {pk: {field: value}}, then _build_replacement_objs does one filter(pk__in=...) and applies all field updates in memory before the swap.
• SearchIndexCreateUpdateImporter._update_search_index_create_or_update — update branch now calls the inherited _delete_then_create_comicfts instead of bulk_update.
• _delete_then_create_comicfts (new, on the m2m sync importer) — does the chunked DELETE + bulk_create inside transaction.atomic so an interrupted run leaves the original row in place rather than a comic with no FTS row at all. _FTS_BATCH_SIZE = 500 keeps the pk__in clause under SQLite's 32k host parameter limit.

Test plan

• make test-python T=tests/importer/ — green.
• ruff check, basedpyright — clean.
• Synthetic bench across 1k / 10k / 50k tables, 100–10k affected, 1 / 3 fields, 5 runs each. Strategy B wins every combo.
• Real-DB validation against ~/Milliways/Comics/full (10,036 ComicFTS rows, deduped via the janitor from Importer search: handle duplicate FTS5 rows / missing FTS_UPDATE entries gracefully #681). Same pattern.

🤖 Generated with Claude Code