various pod fixes
Arthur Axel 'fREW' Schmidt [Fri, 2 Apr 2010 16:49:01 +0000 (11:49 -0500)]
lib/DBIx/Class/DeploymentHandler.pm
lib/DBIx/Class/DeploymentHandler/Dad.pm
lib/DBIx/Class/DeploymentHandler/HandlesVersioning.pm
lib/DBIx/Class/DeploymentHandler/VersionStorage/Standard.pm

index 394a16e..1a21ff2 100644 (file)
@@ -32,6 +32,10 @@ __PACKAGE__->meta->make_immutable;
 
 1;
 
+#vim: ts=2 sw=2 expandtab
+
+__END__
+
 =head1 SYNOPSIS
 
  use aliased 'DBIx::Class::DeploymentHandler' => 'DH';
@@ -131,6 +135,17 @@ of the tables
 
 Install the version storage and not the rest of the tables
 
-__END__
+=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;
 
-vim: ts=2 sw=2 expandtab
+Then, bump your schema version, and you can use DBICDH like normal!
index fcdd868..2051cd2 100644 (file)
@@ -107,7 +107,7 @@ returned from L</upgrade_single_step>.
  $dh->downgrade
 
 Downgrades the database one step at a time till L</previous_version_set>
-returns C<undef>.  Each downgrade step will delete a C<version>from the
+returns C<undef>.  Each downgrade step will delete a C<version> from the
 version storage.
 
 =method backup
@@ -169,7 +169,7 @@ see L<DBIx::Class::DeploymentHandler::HandlesDeploy/prepare_install>
 
 =head2 prepare_resultsource_install
 
-see L<DBIx::Class::DeploymentHandler::HandlesDeploy/prepare_resultsouce_install>
+see L<DBIx::Class::DeploymentHandler::HandlesDeploy/prepare_resultsource_install>
 
 =head2 install_resultsource
 
index 43f7ffb..47690e6 100644 (file)
@@ -11,13 +11,18 @@ __END__
 
 =head1 DESCRIPTION
 
-Typically a VersionHandler will take a to_version and yeild an iterator of
+Typically a VersionHandler will take a C<to_version> and yeild an iterator of
 "version sets."
 
-A "version set" is basically an arrayref of "version numbers" (which we
-already know is vague as is.)  Typically a call to a VersionHandler's
-L</next_version_set> with a db version of 1 and a "to_version" of 5 will
-iterate over something like the following:
+A "version set" could be defined as:
+
+ subtype 'Version', as 'Str';
+ subtype 'VersionSet', as 'ArrayRef[Str]';
+
+and all a "version set" does is uniquely identify a migration.
+
+Typically a call to a VersionHandler's L</next_version_set> with a C<db_version>
+of 1 and a C<to_version> of 5 will iterate over something like the following:
 
  [1, 2]
  [2, 3]
@@ -30,7 +35,7 @@ or maybe just
  [1, 5]
  undef
 
-Really how the version set's are arranged is up to the VersionHandler being
+Really how the version sets are arranged is up to the VersionHandler being
 used.
 
 In some cases users will not want versions to have inherent "previous
index 9617023..8acb6a8 100644 (file)
@@ -37,19 +37,4 @@ __PACKAGE__->meta->make_immutable;
 
 __END__
 
-=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!
-
 vim: ts=2 sw=2 expandtab