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_deploy;
    $dh->prepare_upgrade({
      from_version => 1,
      to_version   => 2,
    });

    $dh->upgrade;

DESCRIPTION
   "DBIx::Class::DeploymentHandler" is, as its 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
   yield the best overall mileage. Each role it uses has its 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?!
   To get up and running fast, your best place to start is
   DBIx::Class::DeploymentHandler::Manual::Intro and then
   DBIx::Class::DeploymentHandler::Manual::CatalystIntro if your intending
   on using this with Catalyst.

   For the full story you should realise that
   "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.

WHY IS THIS SO WEIRD
   "DBIx::Class::DeploymentHandler" has a strange structure. The gist is
   that it delegates to three small objects that are proxied to via
   interface roles that then create the illusion of one large, monolithic
   object. Here is a diagram that might help:

Figure 1
                   +------------+
                   |            |
      +------------+ Deployment +-----------+
      |            |  Handler   |           |
      |            |            |           |
      |            +-----+------+           |
      |                  |                  |
      |                  |                  |
      :                  :                  :
      v                  v                  v
 /-=-------\        /-=-------\       /-=----------\
 |         |        |         |       |            |  (interface roles)
 | Handles |        | Handles |       |  Handles   |
 | Version |        | Deploy  |       | Versioning |
 | Storage |        |         |       |            |
 |         |        \-+--+--+-/       \-+---+---+--/
 \-+--+--+-/          |  |  |           |   |   |
   |  |  |            |  |  |           |   |   |
   |  |  |            |  |  |           |   |   |
   v  v  v            v  v  v           v   v   v
+----------+        +--------+        +-----------+
|          |        |        |        |           |  (implementations)
| Version  |        | Deploy |        |  Version  |
| Storage  |        | Method |        |  Handler  |
| Standard |        | SQLT   |        | Monotonic |
|          |        |        |        |           |
+----------+        +--------+        +-----------+
   The nice thing about this is that we have well defined interfaces for
   the objects that comprise the "DeploymentHandler", the smaller objects
   can be tested in isolation, and the smaller objects can even be swapped
   in easily. But the real win is that you can subclass the
   "DeploymentHandler" without knowing about the underlying delegation; you
   just treat it like normal Perl and write methods that do what you want.

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, define the version in your main schema file (maybe using
   $VERSION).

   Then you'll want to just install the version_storage:

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

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

   Then set your database version:

    $dh->add_database_version({ version => $s->schema_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. It the standard six log levels; "fatal",
   "error", "warn", "info", "debug", and "trace". Most of those are pretty
   self explanatory. Generally a safe level to see what all is going on is
   debug, which will give you everything except for the exact SQL being
   run.

   To enable the various logging levels all you need to do is set an
   environment variables: "DBICDH_FATAL", "DBICDH_ERROR", "DBICDH_WARN",
   "DBICDH_INFO", "DBICDH_DEBUG", and "DBICDH_TRACE". Each level can be set
   on its own, but the default is the first three on and the last three
   off, and the levels cascade, so if you turn on trace the rest will turn
   on automatically.

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 Matthew 25: Ministries:
   <http://www.m25m.org/>, but there are a host of other charities that can
   do much more good than I will with your money. (Third party charity info
   here:
   <http://www.charitynavigator.org/index.cfm?bay=search.summary&orgid=6901
   >

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 <[email protected]>

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

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.