Ecto migration helpers users invoke from their own migration files.

A fresh install

defmodule MyApp.Repo.Migrations.AddScribaTables do
  use Ecto.Migration

  def up, do: Scriba.Migrations.up()
  def down, do: Scriba.Migrations.down()
end

up/1 brings the schema to the latest version: scriba_positions (per-stream cursors), scriba_dead_letters (§9) and scriba_watermarks (the contiguous global position per projection).

Upgrading an existing install

Schema changes ship as numbered steps, and :from says which one you already have. A projection running Scriba 0.1.x has version 1, so:

defmodule MyApp.Repo.Migrations.UpgradeScriba do
  use Ecto.Migration

  def up, do: Scriba.Migrations.up(from: 1)
  def down, do: Scriba.Migrations.down(to: 1)
end

Which steps exist:

Scriba tracks no migration state of its own — the version lives in your migration files, where Ecto already records what ran. That is why :from is explicit rather than detected: guessing wrong would either skip a step or re-run one, and your migration file is the thing that knows.

Every step is idempotent (create_if_not_exists), which matters more than it looks. Your original migration called up(), and up() means "latest" — so on a fresh database it now creates the version 2 table too, and the upgrade migration you added runs second and finds it already there. Without idempotent steps that combination fails for every new deployment of your app while working fine on the ones you were upgrading.

All tables are owned by the user's repo.

stream_id constraint

stream_id is varchar(255). Adapters whose native stream identifiers are richer (UUIDs, integers, composite keys) must convert to a string at the boundary. This is a deliberate simplification — it lets the position cursor schema and ETS keys share one type without per-adapter generics.