StatifierRouter.Migrations.V04 (StatifierRouter v0.9.2)

Copy Markdown View Source

V04 of the package DDL: the location table, which holds the BasicHTTP location token of each address row a configuration with :basichttp mints one for (ADR-0002, the Amendment of 2026-09-30, decision 1). It is named by StatifierRouter.Config.table/2 under the host's table prefix and created in the host's Postgres schema when one is set.

locations:

ColumnTypeNull
idbigserial, primary keyno
address_idthe address table's key type, referencing its id, ON DELETE CASCADEno
tokentextno
inserted_atutc_datetime_usecno

Indexes: the unique <table>_address_id_index on address_id, one location per address row, and the unique <table>_token_index on token, which the front reads a location by.

The reference cascades, so a row StatifierRouter.Addresses.reap/2 deletes takes its location with it, and a delivery that rolls back its address row rolls back its location too.

A table of its own rather than a column on the address table: the package reads and writes it only on a configuration that sets :basichttp, so a host that does not use BasicHTTP never needs this version, and a host that runs it and leaves the key unset gets an empty table nothing reads.

The layout options and :primary_key of StatifierRouter.Migrations apply here on V01's terms: :leading_columns go immediately after id, timestamps_position: :leading moves inserted_at to follow them, and :primary_key types this table's id and the address_id reference alike, so a host that built V01 under :primary_key passes the same option here. Without it, the reference takes the repo's own foreign key type, which matches the address table's id when V01 was built without the option too.

V04 is opt-in, outside the version walk. StatifierRouter.Migrations.up/1 and down/1 never run it, capped or not, so a host that never sets :basichttp sees every migration answer as before V04 existed. A host that sets the key runs it through StatifierRouter.Migrations.up_locations/1 and StatifierRouter.Migrations.down_locations/1 (that module's "The location table, V04, is opt-in"), as ADR-0002, the Amendment of 2026-09-30 "the location table is opt-in, outside the version walk", decides.

up/1 creates the table and its indexes only where they do not exist yet, and down/1 drops the table only if it is there, as V03 renames only what it finds. Because the table references the address table, it has to be dropped before V01's tables are: a host's migration that runs up_locations/1 rolls back before the migration that created them.

Summary

Types

The resolved storage and layout options StatifierRouter.Migrations hands each version.

Functions

Drops the V04 table if it is there; the Postgres schema and the earlier tables stay.

Creates the V04 table and its indexes.

Types

storage()

@type storage() :: %{
  :table_prefix => String.t(),
  :prefix => String.t() | nil,
  optional(:leading_columns) => [{atom(), {term(), keyword()}}],
  optional(:timestamps_position) => :trailing | :leading,
  optional(:column_collations) => [{atom(), String.t()}],
  optional(:primary_key) => keyword() | nil
}

The resolved storage and layout options StatifierRouter.Migrations hands each version.

Functions

down(map)

@spec down(storage()) :: :ok

Drops the V04 table if it is there; the Postgres schema and the earlier tables stay.

up(storage)

@spec up(storage()) :: :ok

Creates the V04 table and its indexes.