Generates the Ecto migration that creates the migrator's checkpoint table.
mix encryptor.ecto.gen.migration [--table NAME] [--migrations-path PATH]The pass records {plan, schema, field, prefix, last_id, counts} after each
batch, inside the batch's own transaction, and --resume starts after the
recorded cursor (ADR-0002 decision 6). The table that lives in is the
host's, and this package will not create it.
This task issues no DDL
It writes one file. Nothing here opens a database connection, and nothing in
this package issues CREATE TABLE at runtime or from a task (ADR-0002
decision 9): Encryptor.Ecto.Migrator.run/2 preflights the table and
refuses, naming this generator, where creating it would have been
convenient. Authoring the DDL and holding authority over the host's schema
are different things, and only the second is refused - so the generated file
is yours the moment it lands: review it in a diff, commit it, and run it
with your own mix ecto.migrate, on your own deploy schedule and with your
own rollback.
Two consequences worth stating, because a generator that looked like an
installer would hide both. The module name is generated from this project's
application name and will need renaming if your repo lives in another
namespace. And a host that will not add the table at all is not stuck: it
runs mix encryptor.ecto.migrate --no-checkpoint, where every run is a full
scan, which probe-first idempotence makes correct rather than merely
tolerable.
Flags
| Flag | ||
|---|---|---|
--table NAME | encryptor_ecto_migration_checkpoints | The table to create. A host that renames it passes the same name as checkpoint_table: to Encryptor.Ecto.Migrator.run/2 |
--migrations-path PATH | priv/repo/migrations | Where to write the file |
Exit codes
0 | The file was written; its path is printed |
2 | Usage error, or a migration for this table already exists in that directory - the generator never overwrites one and never writes a second |
The shape it writes
One row per field per prefix, with a unique index over
{plan, schema, field, prefix}. prefix is NOT NULL with an empty-string
default rather than nullable, because a NULL component defeats the unique
index in every adapter that treats NULLs as distinct - which would let two
rows exist for the default prefix and make the upsert stop finding the row
it wrote last time. last_id is text because both integer and binary
primary keys are supported and one checkpoint table serves both.