Database tasks
The active-record db:* tasks manage the database lifecycle: creating and dropping it,
running and inspecting migrations, and seeding. They act on the active
environment's configured connections (all of them for a multi-database setup);
migration-state tasks report on the primary connection.
Lifecycle
1 2 3 4 5 | |
db:create and db:drop operate on the database itself (the file for SQLite,
the CREATE DATABASE / DROP DATABASE for PostgreSQL and MySQL). db:setup
and db:reset are the full rebuild paths; db:prepare is the idempotent one
that seeds a freshly created database but leaves an existing one untouched.
Migrating
1 2 3 4 5 6 7 | |
db:migrate VERSION=NNN brings the schema to exactly that version: it applies
every pending migration at or below the target and rolls back every applied
migration above it. VERSION=0 rolls everything back.
Inspecting
1 2 3 4 | |
db:check verifies, without changing anything, that every database the active
environment expects exists and has all its migrations applied. It exits non-zero
and prints one line per problem when something is missing or behind, so it works
as a pre-flight before a deploy or a test run.
db:migrate:status prints one line per migration:
1 2 3 | |
db:abort_if_pending_migrations is the guard to put in front of a deploy or a
test run: it exits 1 (and lists the pending versions) when the schema is
behind, and 0 otherwise.
Seeding
1 | |
Runs db/seeds.raku, an ordinary Raku script that uses the ORM to insert
records. It runs in the CLI process against the active connection, so it loads
its own models:
1 2 3 4 5 | |
db:setup, db:reset, and a new-database db:prepare all run the seeds as
their last step.
Test database
1 2 | |
These ready the test environment's database. For the parallel test setup (the
per-worker databases behave uses), db:create, db:migrate, db:check, and
db:reset accept --parallel, which targets every worker copy instead of the
single base database. The worker count comes from the test environment's
parallel key in config/application.json (or an explicit --parallel=N):
1 2 3 4 | |
A parallel db:reset drops every worker table and is non-interactive, so it
requires --yes (or AR_ASSUME_YES=1).
Schema dump and load
1 2 3 | |
db/schema.raku is a Migration subclass that recreates the tables with the
migration DSL, plus the list of applied versions. Foreign keys are introspected
and reproduced: on PostgreSQL and MySQL as add-foreign-key statements after
every table is created, and on SQLite as inline references adverbs on the
column (SQLite cannot add a foreign key to an existing table). The dump remains
lossy for column limits and defaults, which are not recoverable through the
introspection API and are omitted. db:schema:load drops every table and
re-runs the dumped up, then records the schema's versions so the app sees the
migrations as applied (the fast alternative to replaying every migration).
db:structure:dump writes the exact, database-specific DDL: the
sqlite_master statements on SQLite, and pg_dump --schema-only /
mysqldump --no-data on PostgreSQL and MySQL. Use it when the schema relies on
features the portable dump cannot represent.
Schema cache
1 2 | |
The schema cache is a YAML snapshot of every table's columns, indexes,
constraints, and sequences, so an app can skip live introspection at boot. Load
it with SchemaCache.load-yaml(:path).