Все сущности переехали с INTEGER AUTOINCREMENT на TEXT ULID (lowercase, internal/ident — единая точка генерации и разбора; oklog/ulid). Инфохэши загрузки — множество (download_infohash, v1/v2 гибридных торрентов): дедуп и сопоставление в поллинге по любому из хешей, magnet-парсер отдаёт оба хеша гибридной ссылки, усечённый v2-хеш v2-only раздач не хранится. Инвариант «не более одной активной загрузки на infohash» вместо снятого unique-индекса держат guarded-методы store в одной write-транзакции (_txlock=immediate): CreateDownloadIfNoActive (приём/adopt, с доносом недостающих хешей), ActivateIfNoOtherActive (retry/recovery/relink, отказ до побочных эффектов), guarded AddInfohashes; SetDownloadState отклоняет терминал→активное как механический бэкстоп. Миграция 0006 — первая Go-миграция goose: пересоздание таблиц при включённых FK, backfill ULID с timestamp из created_at (хронология id сохранена), разнос infohash, удаление idempotency_key. BREAKING: формат id в URL/логах/Telegram, REST-поля id (string) и infohashes (список). Новая конвенция docs/conventions/database.md (без числовых PK), корреляция в логах grep'ом по голому ULID, ER-схема обновлена. Спеки: новая capability identity, MODIFIED в state-reconciliation; change заархивирован. Пройдены ревью дизайна и кода (по 8 углов), все находки исправлены с регрессионными тестами. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.4 KiB
3.4 KiB
Конвенция: база данных и идентификаторы
Как мы устраиваем таблицы и ключи в SQLite. Актуальная схема —
../specs/database.md; обоснование выбора ULID —
openspec/changes/ulid-identity/design.md (после архивации — в истории git).
Первичные ключи — ULID, не автоинкремент
- PK сущности — TEXT ULID (26 символов Crockford base32), генерируется
приложением в момент создания записи.
INTEGER PRIMARY KEY AUTOINCREMENTв новых таблицах не используем. - Почему ULID: сортируем по времени создания (
ORDER BY id= хронология), компактен и удобен в URL/логах (без дефисов — grep и двойной клик берут id целиком), глобально уникален across таблиц — поиск по голому id находит все записи сущности в логах. - Единственная точка генерации и разбора —
internal/ident:ident.NewID()при создании (в Create-методахstore),ident.Parse()на входных границах. Никаких самодельных генераторов.
Канонический вид — lowercase
- Генерим и храним id в нижнем регистре. Сравнение строк в SQLite
побайтовое, поэтому любой внешний id (URL, форма, callback-data)
ОБЯЗАТЕЛЬНО проходит
ident.Parseдо запроса к БД — он валидирует формат и нормализует регистр (base32 ULID case-insensitive при декодировании). - Синтаксически невалидный id трактуем как несуществующую сущность (404), без похода в БД.
Естественные и составные ключи — для деталей
- У таблиц-деталей/связей допустим естественный или составной ключ вместо
ULID, когда он есть по природе данных:
download_infohash— PK(infohash, download_id),override—UNIQUE(download_id, field). Отдельный ULID там — мёртвый вес. - Прочие генерируемые идентификаторы (например,
apply_batch_id) — тоже черезident.NewID(): единый формат, сортируемость, корреляция в логах.
Прочее
- Enum-поля (
state,kind, …) — обычныйTEXTбезCHECK; допустимые значения держит код (internal/store). - Временные метки —
TEXT DEFAULT (datetime('now'))(UTC), форматstore.ParseTime/FormatTime. - Миграции — goose (
internal/store/migrations): SQL-файлы для DDL; Go-миграции (goose.AddMigrationContext) — когда нужен код (генерация id, backfill). При изменении структуры обновляем ER-схему ../specs/database.md в том же change.