Ubuntu Manpage: DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator

Provided by: libdbix-class-deploymenthandler-perl_0.002208-1_all

NAME

       DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator - Manage your SQL and Perl
       migrations in nicely laid out directories

DESCRIPTION

       This class is the meat of DBIx::Class::DeploymentHandler.  It takes care of generating
       serialized schemata  as well as sql files to move from one version of a schema to the
       rest.  One of the hallmark features of this class is that it allows for multiple sql files
       for deploy and upgrade, allowing developers to fine tune deployment.  In addition it also
       allows for perl files to be run at any stage of the process.

       For basic usage see DBIx::Class::DeploymentHandler::HandlesDeploy.  What's documented here
       is extra fun stuff or private methods.

DIRECTORY LAYOUT

Arguably this is the best feature of DBIx::Class::DeploymentHandler. It's spiritually
based upon DBIx::Migration::Directories, but has a lot of extensions and modifications, so
even if you are familiar with it, please read this. I feel like the best way to describe
the layout is with the following example:

So basically, the code

$dm->deploy(1)

on an "SQLite" database that would simply run
"$sql_migration_dir/SQLite/deploy/1/001-auto.sql". Next,

$dm->upgrade_single_step([1,2])

would run "$sql_migration_dir/SQLite/upgrade/1-2/001-auto.sql" followed by
"$sql_migration_dir/_common/upgrade/1-2/002-generate-customers.pl", and finally punctuated
by "$sql_migration_dir/_common/upgrade/_any/999-bump-action.pl".

".pl" files don't have to be in the "_common" directory, but most of the time they should
be, because perl scripts are generally database independent.

Note that unlike most steps in the process, "initialize" will not run SQL, as there may
not even be an database at initialize time. It will run perl scripts just like the other
steps in the process, but nothing is passed to them. Until people have used this more it
will remain freeform, but a recommended use of initialize is to have it prompt for
username and password, and then call the appropriate "CREATE DATABASE" commands etc.

Directory Specification
The following subdirectories are recognized by this DeployMethod:

"_source" This directory can contain the following directories:
"deploy" This directory merely contains directories named after schema versions, which
in turn contain "yaml" files that are serialized versions of the schema at that version.
These files are not for editing by hand.
"_preprocess_schema" This directory can contain the following directories:
"downgrade" This directory merely contains directories named after migrations, which are
of the form "$from_version-$to_version". Inside of these directories you may put Perl
scripts which are to return a subref that takes the arguments "$from_schema,
$to_schema", which are SQL::Translator::Schema objects.
"upgrade" This directory merely contains directories named after migrations, which are
of the form "$from_version-$to_version". Inside of these directories you may put Perl
scripts which are to return a subref that takes the arguments "$from_schema,
$to_schema", which are SQL::Translator::Schema objects.
$storage_type This is a set of scripts that gets run depending on what your storage type
is. If you are not sure what your storage type is, take a look at the producers listed
for SQL::Translator. Also note, "_common" is a special case. "_common" will get merged
into whatever other files you already have. This directory can contain the following
directories itself:
"initialize" Gets run before the "deploy" is "deploy"ed. Has the same structure as the
"deploy" subdirectory as well; that is, it has a directory for each schema version.
Unlike "deploy", "upgrade", and "downgrade" though, it can only run ".pl" files, and the
coderef in the perl files get no arguments passed to them.
"deploy" Gets run when the schema is "deploy"ed. Structure is a directory per schema
version, and then files are merged with "_common" and run in filename order. ".sql"
files are merely run, as expected. ".pl" files are run according to "PERL SCRIPTS".
"upgrade" Gets run when the schema is "upgrade"d. Structure is a directory per upgrade
step, (for example, "1-2" for upgrading from version 1 to version 2,) and then files are
merged with "_common" and run in filename order. ".sql" files are merely run, as
expected. ".pl" files are run according to "PERL SCRIPTS".
"downgrade" Gets run when the schema is "downgrade"d. Structure is a directory per
downgrade step, (for example, "2-1" for downgrading from version 2 to version 1,) and
then files are merged with "_common" and run in filename order. ".sql" files are merely
run, as expected. ".pl" files are run according to "PERL SCRIPTS".

Note that there can be an "_any" in the place of any of the versions (like "1-2" or 1),
which means those scripts will be run every time. So if you have an "_any" in
"_common/upgrade", that script will get run for every upgrade.

PERL SCRIPTS

       A perl script for this tool is very simple.  It merely needs to contain an anonymous sub
       that takes a DBIx::Class::Schema and the version set as it's arguments.

       A very basic perl script might look like:

        #!perl

        use strict;
        use warnings;

        use DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator::ScriptHelpers
           'schema_from_schema_loader';

        schema_from_schema_loader({ naming => 'v4' }, sub {
          my $schema = shift;

          # [1] for deploy, [1,2] for upgrade or downgrade, probably used with _any
          my $versions = shift;

          $schema->resultset('Users')->create({
            name => 'root',
            password => 'root',
          })
        })

       Note that the above uses "schema_from_schema_loader" in
       DBIx::Class::DeploymentHanlder::DeployMethod::SQL::Translator::ScriptHelpers.  Using a raw
       coderef is strongly discouraged as it is likely to break as you modify your schema.

ATTRIBUTES

ignore_ddl
This attribute will, when set to true (default is false), cause the DM to use
SQL::Translator to use the "_source"'s serialized SQL::Translator::Schema instead of any
pregenerated SQL. If you have a development server this is probably the best plan of
action as you will not be putting as many generated files in your version control. Goes
well with with "databases" of "[]".

force_overwrite
When this attribute is true generated files will be overwritten when the methods which
create such files are run again. The default is false, in which case the program will die
with a message saying which file needs to be deleted.

schema
The DBIx::Class::Schema (required) that is used to talk to the database and generate the
DDL.

storage
The DBIx::Class::Storage that is actually used to talk to the database and generate the
DDL. This is automatically created with "_build_storage".

sql_translator_args
The arguments that get passed to SQL::Translator when it's used.

script_directory
The directory (default 'sql') that scripts are stored in

databases
The types of databases (default "[qw( MySQL SQLite PostgreSQL )]") to generate files for

txn_wrap
Set to true (which is the default) to wrap all upgrades and deploys in a single
transaction.

schema_version
The version the schema on your harddrive is at. Defaults to
"$self->schema->schema_version".

AUTHOR

       Arthur Axel "fREW" Schmidt <frioux+cpan@gmail.com>

COPYRIGHT AND LICENSE

       This software is copyright (c) 2013 by Arthur Axel "fREW" Schmidt.

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

perl v5.18.1                   DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator(3pm)