Adriano/TieMeasureFlow
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Manca la migrazione di base: su DB vuoto il container server non parte #6

New Issue
Closed
opened 2026-09-21 20:14:37 +00:00 by Adriano · 3 comments
Adriano commented 2026-09-21 20:14:37 +00:00
Owner
Copy Link
Copy Source

GRAVITÀ: alta
FILE: src/backend/migrations/versions/001_add_image_path_to_recipe_and_subtask.py:20 ; Dockerfile:36-40
COSA: la catena Alembic parte con add_column su recipes; il CMD è alembic upgrade head && uvicorn. Su DB vuoto alembic fallisce, uvicorn non parte, /api/setup/init-db (l'unico create_all, setup.py:242) non è raggiungibile.
INPUT: prima installazione su MySQL vuoto (il caso on-premise dal cliente).
VERIFICATO: catena su SQLite vuoto → "Running upgrade -> 001_image_path" poi "OperationalError no such table: recipes". grep -n "stamp|has_table" su migrations, main.py, setup.py → 0.
PRESUNTO: con tabelle nate da create_all senza alembic stamp, al riavvio la 001 va in "Duplicate column" e il container entra in crash loop.

ORIGINE: revisione fable del 21/09/2026 su ramo V3.0.0, commit 8cc5e82. Documento completo: _output/2026-09-21-TieMeasureFlow-revisione.md su Wasabi.

GRAVITÀ: alta FILE: src/backend/migrations/versions/001_add_image_path_to_recipe_and_subtask.py:20 ; Dockerfile:36-40 COSA: la catena Alembic parte con `add_column` su `recipes`; il CMD è `alembic upgrade head && uvicorn`. Su DB vuoto alembic fallisce, uvicorn non parte, `/api/setup/init-db` (l'unico `create_all`, setup.py:242) non è raggiungibile. INPUT: prima installazione su MySQL vuoto (il caso on-premise dal cliente). VERIFICATO: catena su SQLite vuoto → "Running upgrade -> 001_image_path" poi "OperationalError no such table: recipes". `grep -n "stamp|has_table"` su migrations, main.py, setup.py → 0. PRESUNTO: con tabelle nate da `create_all` senza `alembic stamp`, al riavvio la 001 va in "Duplicate column" e il container entra in crash loop. ORIGINE: revisione fable del 21/09/2026 su ramo `V3.0.0`, commit 8cc5e82. Documento completo: `_output/2026-09-21-TieMeasureFlow-revisione.md` su Wasabi.
Adriano added the bug label 2026-09-21 20:14:37 +00:00
Adriano added the assegnata:jeeg label 2026-09-21 20:22:11 +00:00
Adriano commented 2026-09-21 20:22:12 +00:00
Author
Owner
Copy Link
Copy Source

⚡ jeeg — preso in carico 2026-09-21T20:22:11Z
ramo: lavoro/jeeg · capacità: docker, gpu, systemd

⚡ jeeg — **preso in carico** 2026-09-21T20:22:11Z ramo: `lavoro/jeeg` · capacità: docker, gpu, systemd
Adriano commented 2026-09-21 20:22:12 +00:00
Author
Owner
Copy Link
Copy Source

ANALISI (passo 1) — ramo lavoro/jeeg, worktree ~/lavoro/TieMeasureFlow su jeeg, lotto A2

MODIFICHE: nuova migrazione src/backend/migrations/versions/000_base_schema.py (revision "000_base", down_revision None) e 001 con down_revision = "000_base". La 000 crea lo schema COM'ERA PRIMA della 001 solo se il DB è vuoto: usa sa.inspect(bind).has_table("recipes"); se la tabella esiste non fa nulla. Lo schema base va scritto esplicito (create_table delle tabelle e colonne pre-001: ricavale dai modelli ORM togliendo ciò che le migrazioni 001–013 aggiungono), NON con Base.metadata.create_all (creerebbe già le colonne delle migrazioni successive e la 001 andrebbe in Duplicate column). Inoltre src/backend/api/routers/setup.py init-db (righe ~242 e ~676): dopo create_all esegui l'equivalente di alembic stamp head (command.stamp con la config di src/backend/migrations/alembic.ini), così un DB nato da create_all non rilancia le migrazioni.
TEST: nuovo test: catena completa upgrade head su SQLite vuoto → riesce e le tabelle coincidono con Base.metadata (nomi tabella e colonne). Secondo test: DB esistente con recipes già presente allo stato pre-001 → la 000 non fa nulla.
NON TOCCARE: Dockerfile (lotto C2).

ANALISI (passo 1) — ramo `lavoro/jeeg`, worktree `~/lavoro/TieMeasureFlow` su jeeg, lotto A2 MODIFICHE: nuova migrazione `src/backend/migrations/versions/000_base_schema.py` (revision "000_base", down_revision None) e `001` con `down_revision = "000_base"`. La 000 crea lo schema COM'ERA PRIMA della 001 solo se il DB è vuoto: usa `sa.inspect(bind).has_table("recipes")`; se la tabella esiste non fa nulla. Lo schema base va scritto esplicito (create_table delle tabelle e colonne pre-001: ricavale dai modelli ORM togliendo ciò che le migrazioni 001–013 aggiungono), NON con `Base.metadata.create_all` (creerebbe già le colonne delle migrazioni successive e la 001 andrebbe in Duplicate column). Inoltre src/backend/api/routers/setup.py `init-db` (righe ~242 e ~676): dopo `create_all` esegui l'equivalente di `alembic stamp head` (command.stamp con la config di src/backend/migrations/alembic.ini), così un DB nato da create_all non rilancia le migrazioni. TEST: nuovo test: catena completa `upgrade head` su SQLite vuoto → riesce e le tabelle coincidono con `Base.metadata` (nomi tabella e colonne). Secondo test: DB esistente con `recipes` già presente allo stato pre-001 → la 000 non fa nulla. NON TOCCARE: Dockerfile (lotto C2).
Adriano commented 2026-09-21 21:56:07 +00:00
Author
Owner
Copy Link
Copy Source

Soluzione

ESITO: fatto
COSA: Nuova migrazione 000_base_schema.py con lo schema pre-001 esplicito, no-op se recipes esiste; la 001 ora discende da 000_base. init-db e reset-db fanno alembic stamp head dopo create_all. Test: upgrade head da SQLite vuoto produce tabelle e colonne uguali a Base.metadata; DB pre-001 esistente → 000 no-op. Verificato anche nell'immagine: alembic heads → 014.
COMMIT (ramo lavoro/jeeg, unito su V3.0.0 a d483fa1): e202995
PROVA: uv run --extra server --extra client --extra dev pytest -q → 622 passed, 4 skipped (erano 391); visione su Python 3.13 → 16 passed (erano 8).

**Soluzione** ESITO: fatto COSA: Nuova migrazione `000_base_schema.py` con lo schema pre-001 esplicito, no-op se `recipes` esiste; la 001 ora discende da `000_base`. `init-db` e `reset-db` fanno `alembic stamp head` dopo `create_all`. Test: upgrade head da SQLite vuoto produce tabelle e colonne uguali a Base.metadata; DB pre-001 esistente → 000 no-op. Verificato anche nell'immagine: `alembic heads` → 014. COMMIT (ramo lavoro/jeeg, unito su V3.0.0 a d483fa1): e202995 PROVA: `uv run --extra server --extra client --extra dev pytest -q` → 622 passed, 4 skipped (erano 391); visione su Python 3.13 → 16 passed (erano 8).
Adriano removed the assegnata:jeeg label 2026-09-21 21:56:08 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
assegnata:daitarn
assegnata:jeeg
attesa:adriano
attesa:cliente
attesa:macchina
bug
Difetto trovato in revisione o in uso
 sviluppo
Sviluppo o miglioria da fare
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Adriano
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Adriano/TieMeasureFlow#6
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?