Module-owned versioned migrations for phoenix_kit_billing — the
decentralized-migrations protocol that core's mix phoenix_kit.update
discovers via migration_module/0: current_version/0 +
migrated_version_runtime/1 + idempotent up/1 + version-aware
down/1. phoenix_kit_legal (over phoenix_kit_consent_logs) is the
closest sibling example of this exact situation — a core-created table
whose future shape a module chain adopts.
Ownership situation — read before touching
phoenix_kit_payment_provider_configs is one of core's V135 baseline
tables. Nothing in this package's lib/ reads or writes it today — it
is currently orphaned application-code-wise, though core still creates
it (and can still roll it back on its own baseline down). Payment
provider credentials this package actually reads and writes today live
in phoenix_kit_settings, via PhoenixKitBilling.Providers — this
version changes NONE of that.
V1 is purely an ADOPTION step:
- on existing installs the table is already there (core V135), the
CREATE TABLE IF NOT EXISTSfinds it, and the only new object is thepkb_schema:1marker — from then on this chain owns the table's future shape; - on a hypothetical future install whose core baseline no longer creates the table, the same statements create it — shape-identical to core's V135, with core's exact index and constraint names.
Because V1 changes no shape, core's ExpectedSchema manifest (which
still audits the V135 shape of this table) stays accurate and NO core
release is required for this version. A version that DOES change shape
(V2+) is a separate, deliberate step — not in scope here.
What down/1 is NOT
down/1 unstamps the version marker; it NEVER drops
phoenix_kit_payment_provider_configs. The table is core-created, and
rolling back this module's chain must not destroy it — only core's own
baseline rollback does that.
The migrated version is tracked as a pkb_schema:<N> COMMENT on
phoenix_kit_payment_provider_configs (the marker convention from the
projects/legal chains, namespaced). A marker-less table reads as
version 0 — the core-baseline shape before this chain existed.
Summary
Functions
Rolls back to target (:version in opts). Never drops the table — see the moduledoc.
The SQL down/1 executes, as data (marker bookkeeping only).
The chain version currently applied in the database, read OUTSIDE a
migration (the protocol shape core's update task calls — opts with
:prefix): the pkb_schema:<N> marker when present; a marker-less or
foreign-comment table reads as 0 (core-baseline shape — V1 is purely
adoptive, there is no pre-chain content to defend).
Applies every chain version up to current_version/0 (idempotent).
The SQL up/1 executes, as data — the testable single source. The
ownership test parses these statements to prove that the object names
are core's V135 names, that the CREATE TABLE stays shape-identical to
core's ExpectedSchema manifest, and that nothing here can drop the
table.
The table carrying the pkb_schema:<N> marker (auditor contract).
Functions
@spec current_version() :: pos_integer()
Rolls back to target (:version in opts). Never drops the table — see the moduledoc.
@spec down_statements(String.t(), non_neg_integer()) :: [String.t()]
The SQL down/1 executes, as data (marker bookkeeping only).
The chain version currently applied in the database, read OUTSIDE a
migration (the protocol shape core's update task calls — opts with
:prefix): the pkb_schema:<N> marker when present; a marker-less or
foreign-comment table reads as 0 (core-baseline shape — V1 is purely
adoptive, there is no pre-chain content to defend).
Applies every chain version up to current_version/0 (idempotent).
The SQL up/1 executes, as data — the testable single source. The
ownership test parses these statements to prove that the object names
are core's V135 names, that the CREATE TABLE stays shape-identical to
core's ExpectedSchema manifest, and that nothing here can drop the
table.
@spec version_table() :: String.t()
The table carrying the pkb_schema:<N> marker (auditor contract).