1.13 Step | InitializeOdooDatabase

Initialises Odoo's base schema in the database. It lives in src/steps/initialize_odoo_database.rs. A port of initialize_odoo_database from lib/odoo.sh.

This is where the hard stop lives: the twin of the anti-drop protection in 1.8 CreateDatabase.

---

The two twin protections

Together they guarantee that a database holding a customer's real data is neither deleted nor altered, on any path:

Protection	Rule	Where
Anti-drop	do not destroy somebody else's data	1.8 CreateDatabase
Hard stop	do not write into somebody else's data	this page

The installer REFUSES to run odoo-bin -i base on a database it did not create. Writing the Odoo schema into a pre-existing database has no clean undo, so the defence is not to do it at all.

The message also covers the most frequent case — the database being the leftover of an earlier interrupted installation rather than a production one — and names all three ways out: sudo invok rollback if that leftover came from an installation this tool registered, a manual sudo -u postgres dropdb <name>, or a different --db-name.

---

How the information gets here (without touching the trait)

The database's PreState is decided by 1.8 CreateDatabase. To propagate it here without modifying the Step trait or the engine:

• CreateDatabase.snapshot publishes the result into a shared ctx.db_created_by_us flag (interior-mutable, so it is writable while receiving &Context);
• InitializeOdooDatabase reads it.

The flag's default is false = refuse: if the information was not propagated (a skipped step, an anomalous order), the init is forbidden. A safe-by-design default.

---

Life cycle

Phase	Behaviour
snapshot	schema already present? → Preexisting (no-op). Schema absent and the database is not ours → hard-stop ERROR. Schema absent and the database is ours → carry on
run	odoo-bin -i base --without-demo=all --stop-after-init as the odoo user, then verify the schema is present
undo	documented NO-OP (see C2)

Checking for the schema comes before the hard stop: a pre-existing database that is already initialised is simply a no-op — there is nothing to write and no harm done.

---

C2 — a non-atomic init, and a no-op undo

The init is not atomic: if it dies halfway, the database is left in an intermediate state. But no incremental repair is attempted (dropping Odoo tables one by one is fragile and wrong). The rule:

Since the init runs only on CreatedByUs databases, cleaning up the schema is covered by 1.8 CreateDatabase's dropdb, which runs after it in reverse order. The database is thrown away and recreated clean.

So the undo here is a no-op. It is the same “absorbed undo” pattern as 1.11 InstallPythonRequirements: the container (the database) owns the removal of its contents (the schema).

---

Design notes

• The init runs as the odoo user, not root.
• Post-init check: if the schema does not turn out to be present → error.
• The hard-stop branch is made impossible to bypass: the flag governs the execution, and the init is unreachable when the database is not ours.
• Tests: hard stop (pre-existing database → error, init never invoked), CreatedByUs (init + no-op undo), schema already present (no-op), and propagation through the engine (the chain stops on the pre-existing database).