[Jifty-commit] r1021 - jifty/trunk/lib/Jifty/Upgrade
jifty-commit at lists.jifty.org
jifty-commit at lists.jifty.org
Sun May 7 18:34:58 EDT 2006
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';
};
More information about the Jifty-commit
mailing list