NAME

Mojolicious::Plugin::Fondation::MigrationDBIx::Command::db - Database migration and fixture commands for DBIx::Class backends

VERSION

version 0.01

SYNOPSIS

$ myapp.pl db bootstrap-schema
$ myapp.pl db prepare
$ myapp.pl db install
$ myapp.pl db status
$ myapp.pl db populate --set 1

DESCRIPTION

Command-line interface for managing database migrations and fixtures for DBIx::Class backends managed by Fondation::Model::DBIx::Async.

Migrations use DBIx::Class::DeploymentHandler directly with ignore_ddl = 1. Upgrade and downgrade SQL are generated on-the-fly from _source/ YAML files -- no db dump step is needed.

NAME

Mojolicious::Plugin::Fondation::MigrationDBIx::Command::db - Database migration and fixture commands

COMMANDS

db bootstrap-schema [--class ClassName] [--backend name] [--force]

Creates a minimal DBIx::Class::Schema class file under lib/. Use this when you have DBIx backends configured but no schema_class yet, or when schema_class is configured but the file does not exist. After creating the file, add schema_class to your backend config (if not already set) and run db prepare to generate migration files.

The generated class uses load_namespaces to auto-discover any Result classes under the application's Schema::Result::* namespace. Result classes from Fondation plugins are registered separately by the DBIx action before workers fork -- both mechanisms coexist transparently.

If schema_class is already configured in your backend, bootstrap-schema uses that class name automatically (no --class needed).

Options

--class ClassName

Full class name for the schema. Defaults to <Moniker>::Schema (e.g. MyApp::Schema when the application moniker is my_app), or to the already-configured schema_class if the backend defines one.

--backend name

Backend name to reference in the post-creation instructions. When omitted, resolves via default_backend_name (same cascade as other db commands: explicit Fondation::MigrationDBIx backend config -> DBIx::Async default_backend -> first backend).

--force

Overwrite the schema file if it already exists.

Local vs plugin Result priority

When both the application and a plugin define a Schema::Result::* class for the same table, the application's class wins: load_namespaces runs during connect(), after the DBIx action has registered plugin sources. The later registration overwrites the earlier one.

This means you can extend or replace a plugin's Result class by defining your own under $AppSchema::Result::* with the same __PACKAGE__->table(...).

db prepare [-y] [-a]

Generates SQL migration files from the schema classes and copies fixture directories from all loaded plugins. Use -y to skip the overwrite prompt.

Before generating, compares the live schema signature against the .schema-sig.json file saved after the last prepare. If the schema has drifted -- for example because a plugin Result class changed after a cpanm upgrade -- the changed sources are reported and the command exits.

Use -a to auto-bump the schema $VERSION and generate the migration. The version is incremented in the class file and in memory; previous migration versions are preserved.

AUTHOR

Daniel Brosseau <dab@cpan.org>

COPYRIGHT AND LICENSE

This software is copyright (c) 2026 by Daniel Brosseau.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.