mirror of
https://github.com/Donkie/Spoolman.git
synced 2026-10-22 10:02:17 -05:00
Donkie
a46cad036f
Adds the five auth_ tables and one DDL-only Alembic revision. Nothing reads or writes them yet; the data layer and endpoints follow in later commits. All five tables are created now, not just the two phase 1 needs. The reason is migrations/env.py's `target_metadata = Base.metadata`: if the database carried auth_api_key while models.py did not, the next autogenerated revision anyone produced would emit op.drop_table for it. Models and schema have to move together, so the phase 2/5 tables land as models now and gain their business logic later. Design notes, all following existing conventions in this schema: - Tables are prefixed auth_ because `user` and `session` are reserved words in PostgreSQL and MySQL, and quoting them at every call site is a footgun. - No relationship() on any auth table. Auth lookups are single-row queries on an indexed column, so there is nothing to eager-load; a `sessions` collection on AuthUser would fetch every session row on every login, and lazy-loading one under asyncio raises MissingGreenlet. - Enum-valued columns (level, actor_kind) are String, matching multi_color_direction. There is not one sa.Enum in this schema, and adding one would create a native PostgreSQL type and a MySQL ENUM(...) with three different ALTER dialects. - Uniqueness is enforced with unique indexes rather than named UNIQUE constraints. That is the portable form across all four dialects, and it keeps the multi-tenancy seam cheap: auth_user.username can later become a composite (tenant_id, username) index without dropping a constraint whose generated name differs per dialect. - The revision is pure DDL with no DML, which is what makes it safe as a single revision on CockroachDB -- the aafcd7fb0e84 -> 304a32906234 split was needed only because the second half wrote data. The revision body is alembic's own autogenerate output against a database at 415a8f855e14, so it matches the conventions of the existing revisions rather than being hand-approximated. Verified on SQLite: upgrade from scratch creates all five tables with the four unique indexes; downgrade -1 drops them all; upgrade replays cleanly. Critically, running autogenerate again after upgrade emits an empty migration, proving the models and the schema agree and that no future autogenerate will try to drop the phase 2/5 tables.