DBIx::C...Handler(3)
π DBIx::Class::DeploymentHandler π
okay bestie, sit down, hydrate, because this is the manual page for DBIx::Class::DeploymentHandler (yep, the DBIx::C...Handler(3) one, section 3, user contributed Perl docs) and she is extensible. Like, "extensible DBIx::Class deployment" is literally what the NAME section says. Extensible. Deployment. Periodt.
β¨ SYNOPSIS β¨
the vibe, in code form:
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, if you're doing the upgrade girlie thing:
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, and I quote the name itself here, a tool for deploying and upgrading databases with DBIx::Class. It's built to be so much more flexible than DBIx::Class::Schema::Versioned β hence the Moose, hence the metric ton of roles. it's giving architecture.
DBIx::Class::DeploymentHandler itself is just a recommended set of roles that the author thinks will not only work well for everyone, but will also yield the best overall mileage. Every role it uses has its own nuances and its own docs, so those aren't all getting described here β but here are a few of the major glow-ups over how DBIx::Class::Schema::Versioned worked (and that DBIx::Class::DeploymentHandler::Deprecated tries to stay compatible with):
- Downgrades in addition to upgrades. yes, *down*grades, we love a reversible queen π
- Multiple sql files files per upgrade/downgrade/install. (that double "files" is canon, bestie, don't @ me)
- 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. (her words, not mine.)
Attributes passed to DBIx::Class::DeploymentHandler::HandlesDeploy
"ignore_ddl" in DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator"databases" in DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator"script_directory" in DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator"sql_translator_args" in DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator"force_overwrite" in DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator"txn_prep" in DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator"txn_wrap" in DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator
Attributes passed to DBIx::Class::DeploymentHandler::HandlesVersioning
initial_version"schema_version" in DBIx::Class::DeploymentHandler::Dad"to_version" in DBIx::Class::DeploymentHandler::Dad
Attributes passed to DBIx::Class::DeploymentHandler::HandlesVersionStorage
version_sourceversion_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?! π¦
ngl, valid question. 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 you're 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. that's the whole squad π«Ά
π 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:
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. main character energy, honestly.
π THIS SUCKS π
You started your project and weren't using "DBIx::Class::DeploymentHandler"? Lucky for you the author had you in mind when writing this doc. (not me being seen.)
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! slay. π
β 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. easy.
π§ DONATIONS π§
If you'd like to thank the author for the work done on this module, don't give them a donation. They spend a lot of free time creating free software, but they do it because they 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 their word on this. They like Matthew 25: Ministries: <http://www.m25m.org/>, but there are a host of other charities that can do much more good than the author 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) 2025 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.
okay that's the whole page bestie, no cap, every last detail intact π and just so you know where this came from: it's perl v5.42.0, dated 2026-01-17, from the User Contributed Perl Documentation collection β so shoutout to the docs girlies, and go deploy something iconic β¨π¦π
π¦ where this page comes from
- fedora 44: perl-DBIx-Class-DeploymentHandler 0.002235-2.fc44 Β· GPL-1.0-or-later OR Artistic-1.0-Perl
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms