NAME
    DBIx::Class::DeploymentHandler - Extensible DBIx::Class deployment

SYNOPSIS
     use aliased 'DBIx::Class::DeploymentHandler' => 'DH';
     my $s = My::Schema->connect(...);

     my $dh = DH->new({
       schema              => $s,
       databases           => 'SQLite',
       sql_translator_args => { add_drop_table => 0 },
     });

     $dh->prepare_install;

     $dh->install;

    or for upgrades:

     use aliased 'DBIx::Class::DeploymentHandler' => 'DH';
     my $s = My::Schema->connect(...);

     my $dh = DH->new({
       schema              => $s,
       databases           => 'SQLite',
       sql_translator_args => { add_drop_table => 0 },
     });

     $dh->prepare_upgrade(1, 2);

     $dh->upgrade;

DESCRIPTION
    "DBIx::Class::DeploymentHandler" is, as it's name suggests, a tool for
    deploying and upgrading databases with DBIx::Class. It is designed to be
    much more flexible than DBIx::Class::Schema::Versioned, hence the use of
    Moose and lots of roles.

    "DBIx::Class::DeploymentHandler" itself is just a recommended set of
    roles that we think will not only work well for everyone, but will also
    yeild the best overall mileage. Each role it uses has it's own nuances
    and documentation, so I won't describe all of them here, but here are a
    few of the major benefits over how DBIx::Class::Schema::Versioned worked
    (and DBIx::Class::DeploymentHandler::Deprecated tries to maintain
    compatibility with):

    *   Downgrades in addition to upgrades.

    *   Multiple sql files files per upgrade/downgrade/install.

    *   Perl scripts allowed for upgrade/downgrade/install.

    *   Just one set of files needed for upgrade, unlike before where one
        might need to generate "factorial(scalar @versions)", which is just
        silly.

    *   And much, much more!

    That's really just a taste of some of the differences. Check out each
    role for all the details.

WHERE IS ALL THE DOC?!
    "DBIx::Class::DeploymentHandler" extends
    DBIx::Class::DeploymentHandler::Dad, so that's probably the first place
    to look when you are trying to figure out how everything works.

    Next would be to look at all the pieces that fill in the blanks that
    DBIx::Class::DeploymentHandler::Dad expects to be filled. They would be
    DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator,
    DBIx::Class::DeploymentHandler::VersionHandler::Monotonic,
    DBIx::Class::DeploymentHandler::VersionStorage::Standard, and
    DBIx::Class::DeploymentHandler::WithReasonableDefaults.

THIS SUCKS
    You started your project and weren't using
    "DBIx::Class::DeploymentHandler"? Lucky for you I had you in mind when I
    wrote this doc.

    First off, you'll want to just install the "version_storage":

     my $s = My::Schema->connect(...);
     my $dh = DBIx::Class::DeploymentHandler->({ schema => $s });

     $dh->prepare_version_storage_install;
     $dh->install_version_storage;

    Then set your database version:

     $dh->add_database_version({ version => $s->version });

    Now you should be able to use "DBIx::Class::DeploymentHandler" like
    normal!

LOGGING
    This is a complex tool, and because of that sometimes you'll want to see
    what exactly is happening. The best way to do that is to use the built
    in logging functionality. Currently three of the standard five log
    levels are used; "info", "debug", and "trace". Info will typically just
    print out when methods that actually change things along with the most
    important args to the method. Debug will give you a little bit more
    information, for example debug will currently tell you which files are
    being run when a migration is being called. Trace of course goes even
    further. It will actually give you the SQL or Perl code being executed
    when a migration is run.

    To enable the various logging levels all you need to do is set some
    environment variables: "DBICDH_INFO", "DBICDH_DEBUG", and
    "DBICDH_TRACE". Each level can be set on it's own, so you can turn on
    trace without turning on info.

    Lastly, the logging uses Log::Contextual, so if you have already set up
    an application-wide logger this will use that logger instead, and the
    environment variables will be completely ignored (unless you did
    something weird like set your logger to log when the above environment
    variables are set.)

DONATIONS
    If you'd like to thank me for the work I've done on this module, don't
    give me a donation. I spend a lot of free time creating free software,
    but I do it because I love it.

    Instead, consider donating to someone who might actually need it.
    Obviously you should do research when donating to a charity, so don't
    just take my word on this. I like Children's Survival Fund:
    <http://www.childrenssurvivalfund.org>, but there are a host of other
    charities that can do much more good than I will with your money.

METHODS
  prepare_version_storage_install
     $dh->prepare_version_storage_install

    Creates the needed ".sql" file to install the version storage and not
    the rest of the tables

  prepare_install
     $dh->prepare_install

    First prepare all the tables to be installed and the prepare just the
    version storage

  install_version_storage
     $dh->install_version_storage

    Install the version storage and not the rest of the tables

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

COPYRIGHT AND LICENSE
    This software is copyright (c) 2010 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.

