Four small follow-ups from the 0.9.0 audit, none of them user-visible: - Migration 0007 drops `chapters_manga_idx`. The 0001 schema declared both `UNIQUE (manga_id, number)` and `CREATE INDEX chapters_manga_idx ON (manga_id, number)`, but Postgres maintains an identical index for the unique constraint automatically — the explicit one was just paying for a second per-write update. Query plans are unchanged because the planner already preferred the constraint's index. - `upload::parse_image` sniffs from the first 64 bytes instead of the full image buffer. `infer` only looks at magic bytes anyway, so scanning 20 MiB is wasted work. Functionally identical; cheaper in the hot path. - AVIF was on the whitelist but had no test fixture. New `avif_bytes` helper produces a minimal `ftyp avif` header that `infer` recognises, and a new `accepts_avif` unit test covers the path end-to-end. - Frontend `request()` sets `credentials: 'include'`. Same-origin callers see no change (default was already `'same-origin'`), but the first user who configures `CORS_ALLOWED_ORIGINS` for a cross-origin deployment gets working cookies without having to chase a runtime ApiError trail. No version bump. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
8 lines
354 B
SQL
8 lines
354 B
SQL
-- `chapters_manga_idx` over (manga_id, number) duplicates the implicit
|
|
-- index Postgres maintains for the `UNIQUE (manga_id, number)`
|
|
-- constraint from 0001 — same leading columns, same ordering, same
|
|
-- selectivity. Dropping the explicit one saves a per-write index
|
|
-- update without changing query plans.
|
|
|
|
DROP INDEX IF EXISTS chapters_manga_idx;
|