9f1b3f6d9a
Pre-resolver rows already had a populated `date_taken` from the old kamadak-exif-only ingest path. The column-add migration left their `date_taken_source` as NULL, and the drain's eligibility predicate (`date_taken IS NULL OR date_taken_source = 'fs_time'`) skips them — so they remain unlabelled forever and never benefit from the resolver's exiftool fallback even if they're videos that should upgrade. Label them all `'exif'` in a one-shot UPDATE. Safe because every write path that populated `date_taken` before the resolver landed was a kamadak-exif read. Idempotent (the WHERE matches nothing on a second run). Down.sql is a no-op — the labels stay correct under any schema state, and the column-add migration is the right place to revert if needed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
10 lines
522 B
SQL
10 lines
522 B
SQL
-- Reverting this migration is a no-op: the labels we wrote in `up.sql`
|
|
-- are correct under any state of the schema (every dated row was indeed
|
|
-- exif-sourced before the resolver landed), and there's no signal that
|
|
-- distinguishes "labelled by this migration" from "labelled by the
|
|
-- ingest path post-resolver". Clearing them would break the drain's
|
|
-- eligibility filter again.
|
|
--
|
|
-- The companion migration `2026-05-06-000000_add_date_taken_source` is
|
|
-- the one to revert if you need to remove the column entirely.
|