# `PhoenixKit.Migrations.Postgres.V116`
[🔗](https://github.com/BeamLabEU/phoenix_kit/blob/v1.7.165/lib/phoenix_kit/migrations/postgres/v116.ex#L1)

V116: Parent reference on entity_data.

Adds a nullable self-referential `parent_uuid` column on
`phoenix_kit_entity_data`, letting each data row point at another row
of the same entity as its parent. The feature is a system field on
every entity_data row — it is always present, optional to fill, and
never removable by the user (it does not appear in
`entities.fields_definition`). Existing rows stay `parent_uuid = NULL`
and become roots; no backfill needed.

The column is nullable (roots have no parent) with **no `ON DELETE`**
cascade: parent/child linkage and same-entity scope are managed by
the `PhoenixKitEntities.EntityData` context, which runs subtree
checks inside a transaction. A DB-level cascade would bypass the
soft-delete machinery and the activity log.

Same-entity enforcement (a row's parent must share its `entity_uuid`)
is a context-layer responsibility — the self-FK has no view of
`entity_uuid`, so the changeset + context perform the lookup before
saving.

A plain b-tree index on `(parent_uuid)` covers the "list children"
query used when rendering the WordPress-style indented tree. Existing
indexes on `(entity_uuid)` and `(entity_uuid, position)` still cover
per-entity listing and manual ordering.

# `down`

Rolls V116 back by dropping the parent index and column.

**Lossy rollback:** the tree collapses — every row becomes a root and
all parent linkage is lost. Back up before rolling back in production.

# `up`

---

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