bvandeusenandClaude Opus 5
573228b9da
CI / lint (push) Failing after 3s
Build images / sign-extension (push) Successful in 4s
CI / extension-version (push) Successful in 3s
Build images / build-agent (push) Successful in 9s
CI / frontend-build (push) Successful in 34s
Build images / build-ml (push) Successful in 53s
Build images / build-web (push) Successful in 44s
CI / backend-lint-and-test (push) Successful in 1m6s
CI / integration (push) Successful in 4m5s
Closes the residue the first reconciliation pass left, and corrects a
factual error I put into the record.
sha256 was NOT missing a uniqueness guarantee. I read
`op.create_index("ix_image_record_sha256", ...)` at 0001 line 151 and
concluded duplicates were possible, without reading line 149 two lines
above it:
sa.UniqueConstraint("sha256", name="uq_image_record_sha256"),
Uniqueness has held since the initial schema. The database expresses it
as a CONSTRAINT plus a separate non-unique lookup index; the model said
`unique=True, index=True`, which is one UNIQUE index under a different
name. Same guarantee, different objects — which is exactly why the two
schemas did not line up. The model now declares both objects. No DDL.
0088's docstring, which repeated the claim, is corrected in place.
Two real divergences, both the MODEL over-claiming:
* source: uq_source_artist_platform_url (alembic 0010) was declared
nowhere in the models — source.py had no __table_args__ at all — so
autogenerate would have proposed DROPPING it.
* head_metrics_snapshot.tag_id: model said NOT NULL, 0060 created it
nullable. Left nullable; the FK already cascades.
Seven constraints renamed to what the chain actually created, rather than
what base.py's naming convention renders: uq_series_page_image,
uq_series_chapter_anchor_page, fk_series_chapter_anchor_page,
fk_image_record_artist_id, fk_image_provenance_from_attachment, and the
two hand-shortened fk_tsr_* names from 0003.
Float server_defaults now mirror their own migration, per column. The
chain is MIXED: a plain string renders DEFAULT '0.90'::double precision,
sa.text() renders DEFAULT 0.90, and the migrations used both. Seven
columns take text(); the rest stay strings. Two literals also disagreed
outright — process_{auto_apply,conflict}_threshold said 0.9/0.5 against
the migration's 0.90/0.50.
baseline.yml gains two things. A repair for a SECOND generator defect in
the same class as the missing pgvector import: base.py's ck convention
contains %(constraint_name)s, so it applies even to a NAMED
CheckConstraint — autogenerate writes the already-rendered name into the
migration and running it applies the convention again, yielding
ck_ml_settings_ck_ml_settings_singleton. That is round-tripping damage,
not a claim the models make, so it is undone rather than counted.
And the diff now runs twice. Column ORDER differs permanently between a
schema built by 87 ADD COLUMNs and one built in a single shot — the
operator's database keeps chain order forever, a fresh install gets model
order — so a check that failed on it could never pass. The second pass
SORTS column lines within each CREATE TABLE instead of deleting them,
which cannot hide a column present on one side only, or one whose type,
nullability or default differs. Ordered diff is reported as information;
the order-insensitive one is the verdict.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017QHszn9H8VBvx5Ke8x1hvw
56 lines
2.3 KiB
Python
56 lines
2.3 KiB
Python
"""Reconcile the database with what the models have always claimed (#3275).
|
|
|
|
Milestone 328 discovered ~130 places where the ORM models and the deployed
|
|
schema disagreed. Almost all of them were the MODEL being wrong — missing
|
|
`server_default`s, indexes and CHECK constraints that only ever existed in a
|
|
migration — and those are fixed in the model files with no DDL at all, because
|
|
the database already had them.
|
|
|
|
This migration carries the remainder: the one case where the MODEL was right
|
|
and the database was missing something.
|
|
|
|
`tag.fandom_id` is declared `index=True` on the model, but no migration ever
|
|
created that index. Every autogenerate run since would have proposed adding
|
|
it; nobody ran one, so the model and the database simply drifted apart and
|
|
stayed that way.
|
|
|
|
Deliberately NOT in this migration: anything about `image_record.sha256`. An
|
|
earlier draft of this file claimed sha256 was not unique in the database and
|
|
that duplicate rows were therefore possible. That was WRONG, and it was wrong
|
|
because it was read off `op.create_index("ix_image_record_sha256", ...)` at
|
|
0001 line 151 without reading line 149 two lines above it:
|
|
|
|
sa.UniqueConstraint("sha256", name="uq_image_record_sha256"),
|
|
|
|
Uniqueness has been enforced since the initial schema. The database simply
|
|
expresses it as a CONSTRAINT plus a separate non-unique lookup index, where
|
|
the model expressed it as one `unique=True, index=True` column — the same
|
|
guarantee built from different objects, which is why the two schemas did not
|
|
line up. The model now declares the constraint and the plain index separately,
|
|
so it describes what is actually there. No DDL is needed for it.
|
|
|
|
Revision ID: 0088
|
|
Revises: 0087
|
|
Create Date: 2026-08-30
|
|
|
|
"""
|
|
from typing import Sequence, Union
|
|
|
|
from alembic import op
|
|
|
|
revision: str = "0088"
|
|
down_revision: Union[str, None] = "0087"
|
|
branch_labels: Union[str, Sequence[str], None] = None
|
|
depends_on: Union[str, Sequence[str], None] = None
|
|
|
|
|
|
def upgrade() -> None:
|
|
# IF NOT EXISTS because the index is what the model already asks for: any
|
|
# database built from metadata rather than from this chain will have it,
|
|
# and this migration must be a no-op there rather than an error.
|
|
op.execute("CREATE INDEX IF NOT EXISTS ix_tag_fandom_id ON tag (fandom_id)")
|
|
|
|
|
|
def downgrade() -> None:
|
|
op.execute("DROP INDEX IF EXISTS ix_tag_fandom_id")
|