# `PhoenixKit.Migrations.Postgres.V144`
[🔗](https://github.com/BeamLabEU/phoenix_kit/blob/v2.13.11/lib/phoenix_kit/migrations/postgres/v144.ex#L1)

V144: Manufacturing/Warehouse module tables consolidation.

Consolidates tables previously created by `phoenix_kit_manufacturing`'s
and `phoenix_kit_warehouse`'s own `migration_module/0` into core's
migration chain — see PR body for the manual-migration note on non-empty
legacy directory tables.

Five objects, each idempotent (safe to re-run):

  * `phoenix_kit_machines` — machine reference-book records. V1 identity
    columns (`name`, `code`, `manufacturer`, `serial_number`,
    `description`, `location_note`, `status`, `data`, `metadata`) plus
    the V2 passport/soft-location columns (`model`, `manufacture_year`,
    `commissioned_on`, `warranty_until`, `to_last_on`,
    `to_interval_days`, `to_next_on`, `notes`, `location_uuid`,
    `space_uuid`), in their final (module V5-equivalent) shape.
  * `phoenix_kit_machine_type_assignments` — machine<->machine_type join.
    `machine_uuid` is a real FK to `phoenix_kit_machines`; `machine_type_uuid`
    is a soft reference to `phoenix_kit_entity_data.uuid` (no FK) — machine
    types now live in `phoenix_kit_entities`, a separate package this
    migration doesn't own. On a host upgrading from the published
    `phoenix_kit_manufacturing` 0.2.0 (module V1), this table already
    exists with a *live* FK on `machine_type_uuid` (pointing at the
    `phoenix_kit_machine_types` directory table below) — `CREATE TABLE IF
    NOT EXISTS` is a no-op there, so the FK is dropped by a separate,
    unconditional step.
  * `phoenix_kit_machine_operations` — machine<->operation join, same
    soft-reference shape on `operation_uuid`. Never published with a live
    FK on any known external host (0.2.0 predates this table entirely),
    but the drop is attempted unconditionally anyway, for symmetry with
    `machine_type_uuid` above.
  * `phoenix_kit_warehouse_transfers` (+ its `number` sequence) and
    `phoenix_kit_warehouse_min_stock` — fresh-install-only DDL. The
    published `phoenix_kit_warehouse` 0.1.0 shipped no migrations at all
    (no `phoenix_kit_warehouse_transfers`/`min_stock` on any external
    host), so there is no upgrade path to account for here, unlike the
    manufacturing tables above.

`phoenix_kit_machine_types`, `phoenix_kit_operations`, and
`phoenix_kit_defect_reasons` — the pre-V5 manufacturing directory tables —
are **not** re-created by this migration; they are not one of the five
objects it owns. If a host still has one of them (realistic only on an
external `phoenix_kit_manufacturing` 0.2.0 install — our own dev database
has never had them, since the module's local migration already carried it
to V5), `up/1` drops it when empty and leaves it in place (with a
`RAISE NOTICE`) when it still holds rows, so real directory data is never
silently destroyed. See the core PR body for the manual data-migration
note on such hosts.

# `down`

Drops the five objects `up/1` owns, in FK-safe order (dependents before
the tables they reference), and restores the version marker to `143`.

**Upgrade-host caveat**: on a host that started from the published
`phoenix_kit_manufacturing` 0.2.0 (module V1), `phoenix_kit_machine_type_assignments`
pre-dates V144 — it was created by that module's own `migration_module/0`,
not by this migration. `down/1` cannot tell the two provenances apart, so
it drops that table unconditionally, which is a stricter rollback than
"undo only what V144 did" on such a host. Does **not** touch
`phoenix_kit_machine_types`, `phoenix_kit_operations`, or
`phoenix_kit_defect_reasons` — those are never owned by V144 (see
moduledoc), so rolling back leaves them exactly as `up/1` found them,
dropped-if-they-were-empty or still in place otherwise.

# `up`

---

*Consult [api-reference.md](api-reference.md) for complete listing*