X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FDeploymentHandler.pm;h=35bef91957198b6aa5a692d1d3d5b3dc665eeb80;hb=a976d6e46695d7015239ee4c30cb3708f4ce7942;hp=fc2ebad9a6614bddd16d6f331b499b97513ae701;hpb=a66bf8996b0752451651ac09a060d991743a941d;p=dbsrgits%2FDBIx-Class-DeploymentHandler.git

diff --git a/lib/DBIx/Class/DeploymentHandler.pm b/lib/DBIx/Class/DeploymentHandler.pm
index fc2ebad..35bef91 100644
--- a/lib/DBIx/Class/DeploymentHandler.pm
+++ b/lib/DBIx/Class/DeploymentHandler.pm
@@ -5,43 +5,49 @@ package DBIx::Class::DeploymentHandler;
 use Moose;
 
 extends 'DBIx::Class::DeploymentHandler::Dad';
+use DBIx::Class::DeploymentHandler::WithApplicatorDumple2;
 # a single with would be better, but we can't do that
 # see: http://rt.cpan.org/Public/Bug/Display.html?id=46347
-with 'DBIx::Class::DeploymentHandler::WithApplicatorDumple' => {
+with WithApplicatorDumple2(
     interface_role       => 'DBIx::Class::DeploymentHandler::HandlesDeploy',
     class_name           => 'DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator',
     delegate_name        => 'deploy_method',
     attributes_to_assume => [qw(schema schema_version)],
-    attributes_to_copy   => [qw( databases script_directory sql_translator_args )],
-  },
-  'DBIx::Class::DeploymentHandler::WithApplicatorDumple' => {
+    attributes_to_copy   => [qw(
+      ignore_ddl databases script_directory sql_translator_args force_overwrite
+    )],
+  ),
+  WithApplicatorDumple2(
     interface_role       => 'DBIx::Class::DeploymentHandler::HandlesVersioning',
     class_name           => 'DBIx::Class::DeploymentHandler::VersionHandler::Monotonic',
     delegate_name        => 'version_handler',
     attributes_to_assume => [qw( database_version schema_version to_version )],
-  },
-  'DBIx::Class::DeploymentHandler::WithApplicatorDumple' => {
+  ),
+  WithApplicatorDumple2(
     interface_role       => 'DBIx::Class::DeploymentHandler::HandlesVersionStorage',
     class_name           => 'DBIx::Class::DeploymentHandler::VersionStorage::Standard',
     delegate_name        => 'version_storage',
     attributes_to_assume => ['schema'],
-  };
+  );
 with 'DBIx::Class::DeploymentHandler::WithReasonableDefaults';
 
 sub prepare_version_storage_install {
   my $self = shift;
 
-  $self->prepare_resultsource_install(
-    $self->version_storage->version_rs->result_source
-  );
+  $self->prepare_resultsource_install({
+    result_source => $self->version_storage->version_rs->result_source
+  });
 }
 
 sub install_version_storage {
   my $self = shift;
 
-  $self->install_resultsource(
-    $self->version_storage->version_rs->result_source
-  );
+  my $version = (shift||{})->{version} || $self->schema_version;
+
+  $self->install_resultsource({
+    result_source => $self->version_storage->version_rs->result_source,
+    version       => $version,
+  });
 }
 
 sub prepare_install {
@@ -86,20 +92,23 @@ or for upgrades:
    sql_translator_args => { add_drop_table => 0 },
  });
 
- $dh->prepare_upgrade(1, 2);
+ $dh->prepare_upgrade({
+   from_version => 1,
+   to_version   => 2,
+ });
 
  $dh->upgrade;
 
 =head1 DESCRIPTION
 
-C<DBIx::Class::DeploymentHandler> is, as it's name suggests, a tool for
+C<DBIx::Class::DeploymentHandler> is, as its name suggests, a tool for
 deploying and upgrading databases with L<DBIx::Class>.  It is designed to be
 much more flexible than L<DBIx::Class::Schema::Versioned>, hence the use of
 L<Moose> and lots of roles.
 
 C<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
+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 L<DBIx::Class::Schema::Versioned> worked (and
 L<DBIx::Class::DeploymentHandler::Deprecated> tries to maintain compatibility
@@ -171,40 +180,38 @@ Install the version storage and not the rest of the tables
 You started your project and weren't using C<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 C<version_storage>:
+First,
+L<define the version|DBIx::Class::DeploymentHandler::Manual::Intro/Sample_database>
+in your main schema file (maybe using C<$VERSION>).
+
+Then you'll want to just install the version_storage:
 
  my $s = My::Schema->connect(...);
- my $dh = DBIx::Class::DeploymentHandler->({ schema => $s });
+ 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->version });
+ $dh->add_database_version({ version => $s->schema_version });
 
 Now you should be able to use C<DBIx::Class::DeploymentHandler> like normal!
 
 =head1 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; C<info>, C<debug>, and C<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: C<DBICDH_INFO>, C<DBICDH_DEBUG>, and C<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 L<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.)
+what exactly is happening.  The best way to do that is to use the built in
+logging functionality.  It the standard six log levels; C<fatal>, C<error>,
+C<warn>, C<info>, C<debug>, and C<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: C<DBICDH_FATAL>, C<DBICDH_ERROR>, C<DBICDH_WARN>, C<DBICDH_INFO>,
+C<DBICDH_DEBUG>, and C<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.
 
 =head1 DONATIONS