"""add code project files and exports
Revision ID: 7570e1707d14
Revises: 001_initial
...
def upgrade() -> None:
passbackend/alembic/versions/7570e1707d14_add_code_project_files_and_exports.py:22
The revision message promises code_project_files and code_project_exports; nothing is created. Those tables only ever come into existence through SQLModel.metadata.create_all() on startup (backend/app/db/engine.py:93).
Trigger: provision a fresh database the documented way — alembic upgrade head — then start the app with init_db disabled or against a Postgres URL where the app user lacks DDL rights.
Observed: alembic_version reads 7570e1707d14, /api/system/db-status happily reports {"ok": true, "revision": "7570e1707d14"} (backend/app/main.py:169), and then the first call to POST /api/v1/code/projects dies on no such table: code_project_files inside crud.bulk_create_project_files (backend/app/db/crud.py:471).
Expected: the migration creates the two tables it is named after, matching CodeProjectFile / CodeProjectExport, and db-status cannot report "current" for a schema that cannot serve a write.
This is the single riskiest piece of drift in the backend: the head revision is a lie, so no future autogenerate can produce a correct diff either.
backend/alembic/versions/7570e1707d14_add_code_project_files_and_exports.py:22The revision message promises
code_project_filesandcode_project_exports; nothing is created. Those tables only ever come into existence throughSQLModel.metadata.create_all()on startup (backend/app/db/engine.py:93).Trigger: provision a fresh database the documented way —
alembic upgrade head— then start the app withinit_dbdisabled or against a Postgres URL where the app user lacks DDL rights.Observed:
alembic_versionreads7570e1707d14,/api/system/db-statushappily reports{"ok": true, "revision": "7570e1707d14"}(backend/app/main.py:169), and then the first call toPOST /api/v1/code/projectsdies onno such table: code_project_filesinsidecrud.bulk_create_project_files(backend/app/db/crud.py:471).Expected: the migration creates the two tables it is named after, matching
CodeProjectFile/CodeProjectExport, anddb-statuscannot report "current" for a schema that cannot serve a write.This is the single riskiest piece of drift in the backend: the head revision is a lie, so no future autogenerate can produce a correct diff either.