1.13 Step | InitializeOdooDatabase

Inizializza lo schema base di Odoo nel database. Vive in src/steps/initialize_odoo_database.rs. Port di initialize_odoo_database di lib/odoo.sh.

Qui vive l'hard-stop: la protezione gemella dell'anti-drop di 1.8 CreateDatabase.

---

Le due protezioni gemelle

Insieme garantiscono che un DB con dati reali del cliente non venga né cancellato né alterato, in nessun percorso:

Protezione	Regola	Dove
Anti-drop	non distruggere dati altrui	1.8 CreateDatabase
Hard-stop	non scrivere in dati altrui	questa pagina

L'installer RIFIUTA di eseguire odoo-bin -i base su un database che non ha creato lui. Scrivere lo schema Odoo dentro un DB preesistente non ha undo pulito, quindi la difesa è non farlo affatto.

Il database '<name>' esisteva già prima dell'installazione; l'inizializzazione dello
schema Odoo è rifiutata per non alterare dati preesistenti. Usa un nome DB diverso o
un DB vuoto creato dall'installer.

---

Come arriva l'informazione (senza toccare il trait)

Il PreState del DB è deciso in Fase 5. Per propagarlo qui senza modificare il trait Step né il motore:

• CreateDatabase.snapshot pubblica il risultato in un flag condiviso ctx.db_created_by_us (interior-mutable, così è scrivibile ricevendo &Context);
• InitializeOdooDatabase lo legge.

Il default del flag è false = rifiuta: se l'informazione non è stata propagata (step saltato, ordine anomalo), l'init è vietato. È un default safe-by-design.

---

Ciclo di vita

Fase	Comportamento
snapshot	schema già presente? → Preexisting (no-op). Schema assente e DB non nostro → ERRORE hard-stop. Schema assente e DB nostro → si procede
run	odoo-bin -i base --without-demo=all --stop-after-init come utente odoo, poi verifica che lo schema sia presente
undo	NO-OP documentato (vedi C2)

La presenza dello schema precede l'hard-stop: un DB preesistente già inizializzato → semplice no-op (non c'è nulla da scrivere, nessun danno).

---

C2 — init non atomico, undo no-op

L'init non è atomico: se muore a metà, il DB resta in stato intermedio. Ma non si tenta alcuna riparazione incrementale (droppare tabelle Odoo una per una è fragile e sbagliato). La regola:

Poiché l'init gira solo su DB CreatedByUs, la pulizia dello schema è coperta dal dropdb di 1.8 CreateDatabase, che gira dopo in ordine inverso. Si butta e si ricrea il DB pulito.

Quindi l'undo qui è un no-op. È lo stesso pattern dell'"undo assorbito" di 1.11 InstallPythonRequirements: il contenitore (il DB) possiede la rimozione del contenuto (lo schema).

---

Note di design

• Init eseguito come utente odoo, non root.
• Verifica post-init: se lo schema non risulta presente → errore.
• Il ramo hard-stop è reso impossibile da aggirare: il flag governa l'esecuzione, e l'init non è raggiungibile quando il DB non è nostro.
• Test: hard-stop (DB preesistente → errore, init mai invocato), CreatedByUs (init + undo no-op), schema già presente (no-op), e la propagazione attraverso il motore (la catena si blocca sul DB preesistente).