X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FDeploymentHandler.pm;h=1a21ff22a8ec4f3a88455acdd5343ef0ee7c623e;hb=d1ae780e6916bf6637bd6ecc2b349c22487df239;hp=093ea627a4f02ab14149a03c1ded637210fe2124;hpb=4a65f60b80222596f851950728f0a115f511481c;p=dbsrgits%2FDBIx-Class-DeploymentHandler.git diff --git a/lib/DBIx/Class/DeploymentHandler.pm b/lib/DBIx/Class/DeploymentHandler.pm index 093ea62..1a21ff2 100644 --- a/lib/DBIx/Class/DeploymentHandler.pm +++ b/lib/DBIx/Class/DeploymentHandler.pm @@ -1,5 +1,7 @@ package DBIx::Class::DeploymentHandler; +# ABSTRACT: Extensible DBIx::Class deployment + use Moose; extends 'DBIx::Class::DeploymentHandler::Dad'; @@ -10,10 +12,140 @@ with 'DBIx::Class::DeploymentHandler::WithSqltDeployMethod', 'DBIx::Class::DeploymentHandler::WithStandardVersionStorage'; with 'DBIx::Class::DeploymentHandler::WithReasonableDefaults'; +sub prepare_version_storage_install { + my $self = shift; + + $self->prepare_resultsource_install( + $self->version_storage->version_rs->result_source + ); +} + +sub install_version_storage { + my $self = shift; + + $self->install_resultsource( + $self->version_storage->version_rs->result_source + ); +} + __PACKAGE__->meta->make_immutable; 1; +#vim: ts=2 sw=2 expandtab + __END__ -vim: ts=2 sw=2 expandtab +=head1 SYNOPSIS + + use aliased 'DBIx::Class::DeploymentHandler' => 'DH'; + my $s = My::Schema->connect(...); + + my $dh = DH->new({ + schema => $s, + databases => 'SQLite', + sqltargs => { 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', + sqltargs => { add_drop_table => 0 }, + }); + + $dh->prepare_upgrade(1, 2); + + $dh->upgrade; + +=head1 DESCRIPTION + +C is, as it's name suggests, a tool for +deploying and upgrading databases with L. It is designed to be +much more flexible than L, hence the use of +L and lots of roles. + +C 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 L worked (and +L tries to maintain compatibility +with): + +=over + +=item * + +Downgrades in addition to upgrades. + +=item * + +Multiple sql files files per upgrade/downgrade/install. + +=item * + +Perl scripts allowed for upgrade/downgrade/install. + +=item * + +Just one set of files needed for upgrade, unlike before where one might need +to generate C, which is just silly. + +=item * + +And much, much more! + +=back + +That's really just a taste of some of the differences. Check out each role for +all the details. + +=head1 WHERE IS ALL THE DOC?! + +C extends +L, 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 roles that fill in the blanks that +L expects to be filled. They would be +L, +L, +L, and +L. + +=method prepare_version_storage_install + + $dh->prepare_version_storage_install + +Creates the needed C<.sql> file to install the version storage and not the rest +of the tables + +=method install_version_storage + + $dh->install_version_storage + +Install the version storage and not the rest of the tables + +=head1 THIS SUCKS + +You started your project and weren't using DBICDH? FOOL! Lucky for you I had +you in mind when I wrote this doc <3 + +First off, you'll want to just install the version_storage: + + my $s = My::Schema->connect(...); + my $dh = DeployHandler({ schema => $s }); + + $dh->prepare_version_storage_install; + $dh->install_version_storage; + +Then, bump your schema version, and you can use DBICDH like normal!