howdy_database - v1.0.0

howdy/migration

Package-owned migrations over Gloo (PostgreSQL and SQLite). Run explicitly during deployment. The list order is the dependency order. SQL must not contain transaction control statements. Published migrations are immutable; append new ones.

Types

Package

</>

A set of migrations owning the schema namespace <name>_.

pub type Package {
  Package(name: String, migrations: List(migration.Migration))
}

Constructors

Values

around_runs

</> 
pub fn around_runs(
  name: String,
  hook: fn(fn() -> Result(Nil, service.Error)) -> Result(
    Nil,
    service.Error,
  ),
) -> Nil

Bracket every later run on this node, whichever packages it applies, for a module that keeps state derived from the database in memory, such as a cache to invalidate. Any package’s migration may rewrite another’s rows. hook must call the function it is given exactly once and return its result; it runs outside the migration transaction. Registering name again replaces its hook. A separate deployment command has no such state and registers nothing.

check

</> 
pub fn check(
  database: repo.Repo,
  package: Package,
) -> Result(Nil, service.Error)

Check compatibility without applying migrations. An older runtime refuses a newer schema, and edited migration SQL is rejected.

per_database

</> 
pub fn per_database(
  postgres postgres: String,
  sqlite sqlite: String,
) -> String

SQL that differs by database, for a migration’s up. Append it to any statements both databases share. The checksum covers both variants, so a migration is the same migration wherever it runs.

gloo_migration.new(2, "add_seen", "CREATE TABLE app_notes (id TEXT);"
  <> migration.per_database(
    postgres: "ALTER TABLE app_notes ADD COLUMN seen TIMESTAMPTZ",
    sqlite: "ALTER TABLE app_notes ADD COLUMN seen BIGINT",
  ))

rebaseline

</> 
pub fn rebaseline(
  database: repo.Repo,
  package: Package,
) -> Result(Nil, service.Error)

Operator escape hatch: accept the owned schema as it is now as the package’s baseline. Catalog output that feeds the fingerprint can change without any real drift, for example after a PostgreSQL major upgrade or a dump and restore. Run this deliberately, from a deployment command and never at startup, after confirming the schema by hand. It refuses unless the recorded migration history exactly matches this package version, so it cannot paper over missing or edited migrations.

run

</> 
pub fn run(
  database: repo.Repo,
  packages: List(Package),
) -> Result(Nil, service.Error)
✨ Search Document