Strict Standards: Redefining already defined constructor for class wpdb in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/wp-db.php on line 49

Deprecated: Assigning the return value of new by reference is deprecated in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/cache.php on line 36

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/cache.php on line 403

Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl($output) in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/classes.php on line 537

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl($output) in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/classes.php on line 537

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el($output) in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/classes.php on line 537

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el($output) in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/classes.php on line 537

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el($output) in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/classes.php on line 556

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl($output) in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/classes.php on line 652

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl($output) in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/classes.php on line 652

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el($output) in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/classes.php on line 652

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el($output) in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/classes.php on line 652

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el($output) in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/classes.php on line 677

Deprecated: Assigning the return value of new by reference is deprecated in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/query.php on line 15

Deprecated: Assigning the return value of new by reference is deprecated in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/theme.php on line 505

Deprecated: Assigning the return value of new by reference is deprecated in /homepages/2/d88602193/htdocs/Rebecca/wp-content/plugins/simpleflickr/phpFlickr/phpFlickr.php on line 92

Deprecated: Assigning the return value of new by reference is deprecated in /homepages/2/d88602193/htdocs/Rebecca/wp-content/plugins/simpleflickr/phpFlickr/phpFlickr.php on line 331

Deprecated: Assigning the return value of new by reference is deprecated in /homepages/2/d88602193/htdocs/Rebecca/wp-content/plugins/simpleflickr/phpFlickr/phpFlickr.php on line 400

Deprecated: Assigning the return value of new by reference is deprecated in /homepages/2/d88602193/htdocs/Rebecca/wp-content/plugins/simpleflickr/phpFlickr/phpFlickr.php on line 469
Rebecca’s Ramblings » Blog Archive » What happens when a migration fails


Strict Standards: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/functions.php on line 11

Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/functions.php on line 20

Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/functions.php on line 22

Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/functions.php on line 24

Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/functions.php on line 25

Strict Standards: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/functions.php on line 11

Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/functions.php on line 20

Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/functions.php on line 22

Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/functions.php on line 24

Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/functions.php on line 25

What happens when a migration fails


Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/formatting.php on line 75

So… you’re writing a migration, you think you’ve got it right - time to try it out. You run
rake db:migrate
to apply your migration, and it doesn’t work.

Your database has some of the changes from the migration in it, and the rest aren’t there. How do you get it back into the state it was in before you attempted the migration?

You might think that
rake db:migrate VERSION=nn
(where nn is the migration number before the one that failed)
would do the job, presuming that your failed migration’s self.down method runs the statements to rollback your changes in the same order as the self.up method makes the changes.

Unfortunately, nothing happens. Rails knows it didn’t complete the migration, so has left the current schema version number as at the end of the last migration which did complete.

At this point, you are faced with opening up your database and reverting the changes that did get made manually…

There is, however, a patch in rails-trac to fix this issue - if you are using a database that supports transactions round data definition statements (such as Postgres). Once installed, your migration is wrapped in a transaction, which is rolled back if any errors occur. Yippee!

2 Responses to “What happens when a migration fails”

  1. ynw Says:

    Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/formatting.php on line 75

    This is probably the most annoyng migration behaviour along with add_column not… reloading columns.

  2. Rebecca Says:

    Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /homepages/2/d88602193/htdocs/Rebecca/wp-includes/formatting.php on line 75

    @ynw:

    Actually, it appears that add_column … does reload column information - when you’re using the development environment. It doesn’t do this in the production environment, though, and if you try to update your new columns using Model.update_attributes you don’t get any messages anywhere to tell you that nothing’s been updated. It all appears to have worked fine.

    Personally, I think this behaviour’s even worse than the original - when you develop the migration, it all works, and when you run it in production, it appears to have worked, but hasn’t actually worked!

Leave a Reply