/ 
DBIx-Class-DeploymentHandler-0.002234
River stage two • 12 direct dependents • 12 total dependents
/ DBIx::Class::DeploymentHandler

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.

ATTRIBUTES

This is just a "stub" section to make clear that the bulk of implementation is documented somewhere else.

Attributes passed to DBIx::Class::DeploymentHandler::HandlesDeploy

Attributes passed to DBIx::Class::DeploymentHandler::HandlesVersioning

Attributes passed to DBIx::Class::DeploymentHandler::HandlesVersionStorage

  • version_source

  • version_class

Attributes Inherited from Parent Class

See "ATTRIBUTES" in DBIx::Class::DeploymentHandler::Dad and "ORTHODOX METHODS" in DBIx::Class::DeploymentHandler::Dad for the remaining available attributes to pass to new.

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

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

This is just a "stub" section to make clear that the bulk of implementation is documented in DBIx::Class::DeploymentHandler::Dad. Since that is implemented using Moose class, see "ATTRIBUTES" in DBIx::Class::DeploymentHandler::Dad and "ORTHODOX METHODS" in DBIx::Class::DeploymentHandler::Dad for methods callable on the resulting object.

new

my $s = My::Schema->connect(...);
my $dh = DBIx::Class::DeploymentHandler->new({
  schema              => $s,
  databases           => 'SQLite',
  sql_translator_args => { add_drop_table => 0 },
});

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) 2024 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.