view release on metacpan or  search on metacpan

README.mkdn  view on Meta::CPAN

## downgrade

Run down files to bring the database down to the previous version from what is
installed to the database

## drop\_tables

Drops all the tables in the connected database with no backup or recovery.  For
real! (Make sure you are not connected to Prod, for example).

## delete\_table\_rows

Does a `delete` on each table in the database, which clears out all your data
but preserves tables.  For Real!  You might want this if you need to load
and unload fixture sets during testing, or perhaps to get rid of data that
accumulated in the database while running an app in development, before dumping
fixtures.

## dump\_named\_sets

Given an array of fixture set names, dump them for the current database version.

## dump\_all\_sets

Takes no arguments just dumps all the sets we can find for the current database
version.

## make\_schema

Given an existing database, reverse engineer a [DBIx::Class](https://metacpan.org/pod/DBIx::Class) Schema in the
["target\_dir"](#target_dir) (under `dumped_db`).  You can use this if you need to bootstrap
your DBIC files.

## populate

Given an array of fixture set names, populate the current database version with
the matching sets for that version.

Skips the table `dbix_class_deploymenthandler_versions`, so you don't lose
deployment info (this is different from ["drop\_tables"](#drop_tables) which does delete it.)

## diagram

Experimental feature.  Although not specifically a migration task, I find it
useful to output visuals of my databases.  This command will place a file in
your ["target\_dir"](#target_dir) called `db-diagram-vXXX.png` where `XXX` is he current
`schema` version.

This is using the Graphviz producer ([SQL::Translator::Producer::GraphViz](https://metacpan.org/pod/SQL::Translator::Producer::GraphViz))
which in turn requires [Graphviz](https://metacpan.org/pod/Graphviz).  Since this is not always trivial to
install, I do not require it.  You will need to add it manually to your
`Makefile.PL` or `dist.ini` and manage it yourself.

This feature is experimental and currently does not offer any options, as I
am still determining the best way to meet the need without exceeding the
scope of [DBIx::Class::Migration](https://metacpan.org/pod/DBIx::Class::Migration).  Consider this command a 'freebee' and
please don't depend on it in your custom code.

## install\_if\_needed

If the database is not installed, do so.  Accepts a hash of callbacks or
instructions to perform should installation be needed/

    $migration->install_if_needed(
      on_install => sub {
        my ($schema, $local_migration) = @_;
        DBIx::Class::Migration::Population->new(
          schema=>shift)->populate('all_tables');
      });

The following callbacks / instructions are permitted

- on\_install

    Accepts: Coderef

    Given a coderef, execute it after the database is installed.  The coderef
    gets passed two arguments: `$schema` and `$self` (the current migration
    object).

- default\_fixture\_sets

    Accepts: Arrayref of fixture sets

        $migration->install_if_needed(
          default_fixture_sets => ['all_tables']);

    After database installation, populate the fixtures in order.

## install\_version\_storage

If the targeted (connected) database does not have the versioning tables
installed, this will install them.  The version is set to whatever your
`schema` version currently is.

You will only need to use this command in the case where you have an existing
database that you are reverse engineering and you need to setup versioning
storage since you can't rebuild the database from scratch (such as if you have
a huge production database that you now want to start versioning).

## delete\_named\_sets

Given a (or a list) of fixture sets, delete them if the exist in the current
schema version.

Yes, this really deletes, you've been warned (check in your code to a source
control repository).

# ENVIRONMENT

When running [DBIx::Class::Migration](https://metacpan.org/pod/DBIx::Class::Migration) we set some `%ENV` variables during
installation, up / downgrading, so that your Perl run scripts (see
["DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator\\'PERL SCRIPTS'"](#dbix-class-deploymenthandler-deploymethod-sql-translator-perl-scripts))
can receive some useful information.  The Following `%ENV` variables are set:

    DBIC_MIGRATION_SCHEMA_CLASS => $self->schema_class
    DBIC_MIGRATION_TARGET_DIR => $self->target_dir
    DBIC_MIGRATION_FIXTURE_DIR => catdir($self->target_dir, 'fixtures', $self->dbic_dh->schema_version),
    DBIC_MIGRATION_SCHEMA_VERSION => $self->dbic_dh->schema_version
    DBIC_MIGRATION_TO_VERSION => $self->dbic_dh->to_version
    DBIC_MIGRATION_DATABASE_VERSION => $self->dbic_dh->schema_version || 0

You might find having these available in your migration scripts useful for
doing things like 'populate a database from a fixture set, if it exists, but
if not run a bunch of inserts.

# THANKS

Because of the awesomeness of CPAN and the work of many others, all this
functionality is provided with a few hundred lines of code.  In fact, I spent
a lot more time writing docs and tests than anything else. Here are some