No Pugs

they're evil

Upgrading via a git merge might not be the best way of upgrading typo. The safest way is probably to follow the instructions in the UPGRADE file. However, I have a few modifications I've made to Typo that I'd like to preserve.

So I went ahead and merged 5_3_0 with my 5.1.3 branch and ran a db:migrate

I couldn't log in anymore. It turns out a "status" column is added to the users table in a migration, and in the same migration, each existing user's status is set to "active"

The problem is that after a db:migrate, the status column was still NULL. What happens is that it works if you run 1 migration at a time. But if you run the migration that adds and sets the status column to "active" in the same rake invocation that has already accessed the User class, it will already have the old columns loaded into it and will not think the "status" column even exists.

To fix it, you need to issue a User.reset_column_information after adding the column.

This column is not the only problem column, the "text_filter_id" and "editor" column also failed to update.

Below is a quick patch I made from my typo repository. I only went back to the migrations I was missing between 5.1.3 and 5.3 and made sure any model classes that were used had "reset_column_information" called before using. If you are going to attempt upgrading your typo blog via a git merge/pull, this patch might be useful.

0001-Changed-some-recent-migrations-to-call.patch

A note about an oddity I ran into when running these migrations in a production environment: You'll need to set config.cache_classes in config/environments/production.rb to false while running the migrations, otherwise it might try to preload information about classes whose tables don't yet exist. I'm not exactly sure why this happens, I've never had this problem in the past.

Published on 12/02/2009 at 10:08PM under , .

2 comments

Powered by Typo – Thème Frédéric de Villamil | Photo Glenn