mix aurora_meter.
View Source
Generates a migration that installs the Aurora Meter tables into the host app.
mix aurora_meter.gen.migration -r MyApp.RepoThe generated migration delegates to AuroraMeter.Migration, so future schema
changes ship as new versions of that module rather than as edits to your
migration file. To upgrade an existing install to a newer schema version:
mix aurora_meter.gen.migration -r MyApp.Repo --from 7which generates migrations running versions 7..latest. See
AuroraMeter.Migration for the version list.
--upgrade, which reads the version rather than being told it
mix aurora_meter.gen.migration -r MyApp.Repo --upgrade--upgrade starts the repo, reads the installed schema version from
aurora_meter_checkpoints["schema:core"] and generates from the next one.
It refuses, with what to do instead, when the marker is absent: that row
arrives with version 7, so its absence means the database has not reached
version 7 and the version has to come from the host's own migrations
directory. It does not guess, because guessing low re-runs migrations that
have already run and guessing high skips ones that have not.
It also refuses when a migration already in priv/repo/migrations covers a
version in the range, naming the file, so running the generator twice cannot
produce a history that applies the same version twice.
Two things the generated files do on purpose
The version range is pinned at both ends. A generated up(from: 7) would
run to whatever the latest version is on the day it first applies, so a
database created today and one created after the next release would run the
same migration file and end up with different schemas. Every generated body
names both ends.
A concurrent version gets a file of its own. Core schema version 8
creates a unique index CONCURRENTLY, which Postgres refuses inside a
transaction block, so its file carries @disable_ddl_transaction true and
@disable_migration_lock true and runs that version and nothing else. A
range that spans one is therefore emitted as several files: one per
contiguous run of ordinary versions, and one per concurrent version, in
order.
A fresh install is the exception: it passes concurrently: false and builds
the index inside the transaction, because there are no rows to lock. Its
down carries confirm_data_loss: true, because undoing an install is
exactly the case where destroying the tables is what was asked for. An
upgrade file's down carries it only when the range it covers holds a
version whose down destroys a commercial fact.
--no-validate-checks, for a database with rows the V1 contract refuses
mix aurora_meter.gen.migration -r MyApp.Repo --from 7 --no-validate-checksAuroraMeter.track/4 never rejected a non-positive quantity and never bounded
metadata, so a database written by 0.4.x can hold rows that core schema
version 8's constraints refuse. mix aurora_meter.events.backfill counts them
and prints the remedy: run version 8 with validate_checks: false, which
leaves those two constraints NOT VALID (still enforced on every new row, and
recorded in the schema marker) instead of proving them against history.
Until build unit 11a the generated file had no way to carry that option, so
the only route from the backfill's advice to a working upgrade was to
hand-edit a generated migration (open-findings.md X428). The flag emits it
on the file covering version 8 and on no other file. Without the flag nothing
is emitted and the default, true, stands.