Fix fallout from svn merge - please don't do it
Peter Rabbitson [Wed, 10 Jun 2009 07:56:44 +0000 (07:56 +0000)]
Also rid of evil tab infestation

VERSIONING.SKETCH [deleted file]
lib/DBIx/Class/Storage/DBI/Replicated.pm
t/105-run-file-against-storage.t [changed mode: 0755->0644]
t/lib/DBICTest.pm
t/lib/DBICTest/AuthorCheck.pm

diff --git a/VERSIONING.SKETCH b/VERSIONING.SKETCH
deleted file mode 100644 (file)
index 03e6ea1..0000000
+++ /dev/null
@@ -1,30 +0,0 @@
-Schema versioning/deployment ideas from Jess (with input from theorbtwo and mst):
-1) Add a method to storage to:
- - take args of DB type, version, and optional file/pathname
- - create an SQL file, via SQLT, for the current schema
- - passing prev. version + version will create an sqlt-diff'ed upgrade file, such as
-  - $preversion->$currentversion-$dbtype.sql, which contains ALTER foo statements.
-2) Make deploy/deploy_statements able to to load from the appropriate file, for the current DB, or on the fly? - Compare against current schema version..
-3) Add an on_connect_cb (callback) thingy to storage.
-4) create a component to deploy version/updates:
- - it hooks itself into on_connect_cb ?
- - when run it:
-   - Attempts or prompts a backup of the database. (commands for these per-rdbms can be stored in storage::dbi::<dbtype> ?)
-   - Checks the version of the current schema being used
-   - Compares it to some schema table containing the installed version
-   - If none such exists, we can attempt to sqlt-diff the DB structure with the schema
-   - If version does exist, we use an array of user-defined upgrade paths,
-    eg: version = '3x.'; schema = '1.x', upgrade paths = ('1.x->2.x', '2.x->3.x')
-   - Find the appropriate upgrade-path file, parse into two chunks:
-    a) the commands which do not contain "DROP"
-    b) the ones that do
-   - Calls user callbacks for "pre-upgrade"
-   - Runs the first set of commands on the DB
-   - Calls user callbacks for "post-alter"
-   - Runs drop commands
-   - Calls user callbacks for "post-drop"
- - The user will need to define (or ignore) the following callbacks:
-  - "pre-upgrade", any code to be run before the upgrade, called with schema object, version-from, version-to, db-type .. bear in mind that here any new fields in the schema will not work, but can be used via scalarrefs.
-  - "post-alter", this is the main callback, at this stage, all old and new fields will be available, to allow data migration.
-  - "post-drop", this is the clean-up stage, now only new fields are available.
-
index fc32ca0..bd878c8 100644 (file)
@@ -2,10 +2,10 @@ package DBIx::Class::Storage::DBI::Replicated;
 
 BEGIN {
   use Carp::Clan qw/^DBIx::Class/;
-       
+
   ## Modules required for Replication support not required for general DBIC
   ## use, so we explicitly test for these.
-       
+
   my %replication_required = (
     Moose => '0.77',
     MooseX::AttributeHelpers => '0.12',
@@ -13,17 +13,16 @@ BEGIN {
     namespace::clean => '0.11',
     Hash::Merge => '0.11'
   );
-       
+
   my @didnt_load;
-  
+
   for my $module (keys %replication_required) {
-       eval "use $module $replication_required{$module}";
-       push @didnt_load, "$module $replication_required{$module}"
-        if $@;
+    eval "use $module $replication_required{$module}";
+    push @didnt_load, "$module $replication_required{$module}" if $@;
   }
-       
+
   croak("@{[ join ', ', @didnt_load ]} are missing and are required for Replication")
-    if @didnt_load;    
+    if @didnt_load;
 }
 
 use Moose;
@@ -278,9 +277,9 @@ has 'write_handler' => (
   is=>'ro',
   isa=>Object,
   lazy_build=>1,
-  handles=>[qw/   
+  handles=>[qw/
     on_connect_do
-    on_disconnect_do       
+    on_disconnect_do
     connect_info
     throw_exception
     sql_maker
@@ -288,7 +287,7 @@ has 'write_handler' => (
     create_ddl_dir
     deployment_statements
     datetime_parser
-    datetime_parser_type        
+    datetime_parser_type
     last_insert_id
     insert
     insert_bulk
@@ -303,11 +302,11 @@ has 'write_handler' => (
     sth
     deploy
     with_deferred_fk_checks
-       run_file_against_storage
+    run_file_against_storage
 
     reload_row
     _prep_for_execute
-    
+
   /],
 );
 
old mode 100755 (executable)
new mode 100644 (file)
index a443f3a..f0b0225 100644 (file)
@@ -129,7 +129,7 @@ sub deploy_schema {
     if ($ENV{"DBICTEST_SQLT_DEPLOY"}) { 
         $schema->deploy($args);    
     } else {
-               $schema->storage->run_file_against_storage(qw/t lib sqlite.sql/);
+      $schema->storage->run_file_against_storage(qw/t lib sqlite.sql/);
     }
     return;
 }
index 578ff15..f89325b 100644 (file)
@@ -34,23 +34,23 @@ sub _check_author_makefile {
   );
 
   return unless $mf_pl_mtime;   # something went wrong during co_root detection ?
-  
+
   my @reasons;
-  
+
   if(not -d $root->subdir ('inc')) {
-       push @reasons, "Missing inc directory";
-  } elsif(not $mf_mtime) {
-       push @reasons, "Missing Makefile";
+    push @reasons, "Missing inc directory";
+  }
+
+  if (not $mf_mtime) {
+    push @reasons, "Missing Makefile";
   } elsif($mf_mtime < $mf_pl_mtime) {
-       push @reasons, "Makefile.PL is newer than Makefile";
+    push @reasons, "Makefile.PL is newer than Makefile";
   }
-  
+
   if (@reasons) {
     print STDERR <<'EOE';
 
 
-
-
 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 ======================== FATAL ERROR ===========================
 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
@@ -59,12 +59,12 @@ Reasons you received this message:
 
 EOE
 
-       foreach my $reason (@reasons) {
-               print STDERR "\t* $reason\n";
-       }
+    foreach my $reason (@reasons) {
+      print STDERR "\t* $reason\n";
+    }
+
+    print STDERR <<'EOE';
 
-       print STDERR <<'EOE';
-       
 We have a number of reasons to believe that this is a development
 checkout and that you, the user, did not run `perl Makefile.PL`
 before using this code. You absolutely _must_ perform this step,
@@ -86,8 +86,8 @@ entirely.
 The DBIC team
 
 EOE
-    
-       exit 1;
+
+    exit 1;
   }
 }