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>
21 lines
1.0 KiB
SQL
21 lines
1.0 KiB
SQL
-- Backfill `date_taken_source` for rows that pre-date the canonical-date
|
|
-- pipeline. Before the resolver landed, `image_exif.date_taken` could
|
|
-- only be populated via `exif::extract_exif_from_path` (kamadak-exif)
|
|
-- on the file-watcher, upload, or GPS-write paths. The resolver column
|
|
-- migration added `date_taken_source` defaulting to NULL, so every
|
|
-- historical row with a date is currently unlabelled — and the
|
|
-- per-tick drain skips them because its eligibility predicate is
|
|
-- `date_taken IS NULL OR date_taken_source = 'fs_time'`.
|
|
--
|
|
-- Label them `'exif'` once and let the drain take over from here. Safe
|
|
-- because every code path that wrote `date_taken` prior to the
|
|
-- resolver was a kamadak-exif read — there was no other source.
|
|
--
|
|
-- Idempotent: re-running this migration on a DB that has already been
|
|
-- backfilled is a no-op (the WHERE clause matches nothing the second
|
|
-- time around).
|
|
UPDATE image_exif
|
|
SET date_taken_source = 'exif'
|
|
WHERE date_taken IS NOT NULL
|
|
AND date_taken_source IS NULL;
|