Versioned migration coordinator for phoenix_kit_knowledge_base — the module
returned from PhoenixKitKnowledgeBase.migration_module/0.
mix phoenix_kit.update discovers this, compares migrated_version_runtime/1
(what's installed) with current_version/0 (what the code needs), and — when
behind — generates a host migration whose up/0 calls up/1 here. The host
installs the five knowledge-base tables with no hand-written migration, and it
honors the host's --prefix (named-schema installs).
Version is tracked via a COMMENT ON TABLE on phoenix_kit_kb_vaults
(mirroring core's own PhoenixKit.Migrations.Postgres and the pattern
documented in phoenix_kit_hello_world's README) rather than a boolean "does
the table exist", so a future V2 can tell "not installed" apart from
"installed at V1".
Tables (V1)
| Table | Holds |
|---|---|
phoenix_kit_kb_vaults | One vault — a self-contained note space |
phoenix_kit_kb_vault_members | Per-vault membership (owner/editor/viewer) |
phoenix_kit_kb_folders | The folder tree inside a vault |
phoenix_kit_kb_notes | Markdown notes, tags, and the search vector |
phoenix_kit_kb_note_links | The [[wiki-link]] index, including unresolved links |
Versions:
0— tables absent (not installed)1— all five tables present, UUIDv7 primary keys2—phoenix_kit_kb_vaults.path_key: the vault a drop-in notes panel's path names (notes_panel path={["CRM", …]}), one shared and one private per person per name3— paths, link targets and vault directories becometext. V1 made themvarchar(255), which a nested folder or a long[[link]]overflows: the insert raised, a save crashed the page, and one such file made every rescan of its vault crash until someone removed it by hand
Summary
Functions
The version this code expects the schema to be at.
Roll back. Migration-context only.
The version currently installed in the database — 0 if the tables are absent,
and also 0 if they exist but match no version this module knows how to
produce. up/1 raises with the details for that second case rather than
migrating unrecognised tables blindly.
Runtime-safe version of migrated_version/1 — uses PhoenixKit's configured
repo instead of the Ecto.Migration repo() helper, so it can be called
from Mix tasks and other non-migration contexts (mix phoenix_kit.update).
Run migrations up to (and including) the target version. Migration-context only.
Functions
@spec current_version() :: pos_integer()
The version this code expects the schema to be at.
@spec down(keyword()) :: :ok
Roll back. Migration-context only.
@spec migrated_version(keyword()) :: non_neg_integer()
The version currently installed in the database — 0 if the tables are absent,
and also 0 if they exist but match no version this module knows how to
produce. up/1 raises with the details for that second case rather than
migrating unrecognised tables blindly.
Migration-context only — reads via Ecto.Migration.repo/0.
@spec migrated_version_runtime(keyword()) :: non_neg_integer()
Runtime-safe version of migrated_version/1 — uses PhoenixKit's configured
repo instead of the Ecto.Migration repo() helper, so it can be called
from Mix tasks and other non-migration contexts (mix phoenix_kit.update).
@spec up(keyword()) :: :ok
Run migrations up to (and including) the target version. Migration-context only.