[Jifty-commit] r1021 - jifty/trunk/lib/Jifty/Upgrade

[jifty-commit at lists.jifty.org]

Author: jesse
Date: Sun May  7 18:34:57 2006
New Revision: 1021

Modified:
   jifty/trunk/lib/Jifty/Upgrade/Internal.pm

Log:
* If users were upgrading from pre->0.60427 versions of Jifty, the table upgrades semantics could bite them as they did the wrong thing
on "repeated" upgrades.



Modified: jifty/trunk/lib/Jifty/Upgrade/Internal.pm
==============================================================================
--- jifty/trunk/lib/Jifty/Upgrade/Internal.pm	(original)
+++ jifty/trunk/lib/Jifty/Upgrade/Internal.pm	Sun May  7 18:34:57 2006
@@ -6,6 +6,9 @@
 use base qw/Jifty::Upgrade/;
 use Jifty::Model::Metadata;
 
+# XXX TODO: there's probably a cleaner way to cope than "INITIAL_VERSION", perhaps using ->VERSIONS
+our $INITIAL_VERSION;
+
 =head2 Version 0.60427
 
 Version metadata, previously stored in _db_version, get migrated to
@@ -18,9 +21,13 @@
     my @v = Jifty->handle->fetch_result("SELECT major, minor, rev FROM _db_version");
     Jifty->handle->simple_query("DROP TABLE _db_version");
     Jifty::Model::Metadata->store( application_db_version => version->new(join'.', at v));
+    # Since we broke things before 0.60504 but fixed them shortly thereafter,
+    # Make sure the user doesn't run the 060504 upgrade unless they must
+    $INITIAL_VERSION = '0.60427';
 };
 
-since '0.60504' => sub {
+since '0.60504' => sub { 
+    return if ($INITIAL_VERSION == '0.60427');
     rename column => 'key', in => 'Jifty::Model::Session',  to => 'data_key';
     rename column => 'key', in => 'Jifty::Model::Metadata', to => 'data_key';
 };