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

V157: Widen `phoenix_kit_annotations_kind_check` for the new
`"image"` kind.

PR #660 exposed Etcher 0.9's `:image` tool in the media viewer's
toolbar (`media_canvas_viewer.html.heex`) without widening the CHECK
constraint (or the schema's `@kinds`) to match — the same regression
V130's moduledoc warns about for `"marker"`. Without this, inserting
an image annotation is rejected by the DB and silently fails to
persist across a reload.

Idempotent: each `ADD CONSTRAINT` is preceded by `DROP CONSTRAINT
IF EXISTS` on the same prefixed table.

## down/1 is conditional, by necessity

Rolling back re-adds the *narrower* CHECK, and Postgres validates
every existing row when a CHECK is added. So the rollback is only
possible while no `kind = 'image'` annotation exists — once a user has
drawn one, the old constraint is not a truthful description of the
data and there is no correct way for a schema migration to assert it.

`down/1` therefore checks first and raises a message naming the row
count and the two ways forward, rather than letting the `ALTER` fail
with an opaque `23514` mid-rollback. The alternatives were both worse:
deleting or rewriting user annotations is data loss a rollback has no
business performing, and `NOT VALID` would leave a constraint that
lies about the rows already in the table.

# `down`

# `up`

---

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