Migrations creating and upgrading the tables, triggers and functions the event store reads and writes.

The schema is versioned. Each version is one step, and up/1 runs every step between the version the database is at and the one asked for, so a fresh install and an upgrade delegate to the same function and an upgrade runs only what the install is missing.

Generate a migration in the host application and delegate to this module:

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

  def up, do: Sourced.EventStore.Postgres.Migrations.up()
  def down, do: Sourced.EventStore.Postgres.Migrations.down()
end

up/1 migrates to the latest version by default and down/1 reverts everything. When a release adds a version, upgrade an existing install with a second migration pinned to it:

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

  def up, do: Sourced.EventStore.Postgres.Migrations.up(version: 2)
  def down, do: Sourced.EventStore.Postgres.Migrations.down(version: 2)
end

down(version: 2) reverts version 2 and anything above it, leaving the database at version 1, so the pair above is one clean step in either direction. Pinning up matters too: a migration that always went to the latest would do different things depending on which release ran it.

Versions

• 1 — sourced_events and sourced_event_tags, their indexes and triggers, and the read watermark functions. What every 0.1.x and 0.2.x release created.
• 2 — sourced_checkpoints, for Sourced.EventStore.Postgres.Subscriber.

The version is recorded as a comment on sourced_events. A database migrated by a release before versioning has the tables and no comment, and is read as version 1.