Cardbox's tables, in versions, for the migrations of your app.

$ mix cardbox.gen.migration

writes a migration that pins the latest version:

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

  def up, do: Cardbox.Migrations.up(version: 1)
  def down, do: Cardbox.Migrations.down(to: 0)
end

A later Cardbox that changes the tables has a new version, and mix cardbox.gen.migration writes the migration that takes them there, from the version your migrations already pin:

def up, do: Cardbox.Migrations.up(version: 2)
def down, do: Cardbox.Migrations.down(to: 1)

So a migration, once written, does the same thing whichever Cardbox runs it: your history is the same for a new developer, in CI and in production. The version a database is at is kept in a table of one row, cardbox_schema, and up/1 runs only the versions after it, so the migrations of an app that made the tables another way run once.

The versions run on PostgreSQL and on SQLite.

Versions

1. The five tables: cardbox_collections, cardbox_fields, cardbox_records (the values a JSON map, with a GIN index and a trigram index of the search text on PostgreSQL), cardbox_links and cardbox_views.