Question

I’m under Rails 3.0.9, with Ruby 1.9.2 (p290).
Using Postgresql 9.0.4, and the ‘pg’ gem v0.11.0

The problem is :

I’ve got a really simple migration just changing the value of a column with conditions :

def self.up
  Closet.reset_column_information
  say_with_time "Unifying gender column to h/f" do
    Closet.connection.update "UPDATE closets AS c SET gender='h' WHERE c.gender IN ('homme', 'Homme', 'men', 'Men');"
    Closet.connection.update "UPDATE closets AS c SET gender='f' WHERE c.gender IN ('femme', 'Femme', 'women', 'Women');"
  end
end

Every request works perfectly in my erb console and in the pgAdmin SQL’s console too, but when I run the migration it says :

PGError: ERROR:  current transaction is aborted, commands ignored until end of transaction block

If anyone as an idea…

Here is bigger part of the error message stack :

== MigrateClosets: migrating =================================================
rake aborted!
An error has occurred, this and all later migrations canceled:

PGError: ERROR:  current transaction is aborted, commands ignored until end of transaction block
: UPDATE closets SET gender='h' WHERE closets.gender  = 'homme';
/Users/gdurelle/.rvm/gems/ruby-1.9.2-p290@dressmeNG/gems/activerecord-3.0.9/lib/active_record/connection_adapters/abstract_adapter.rb:207:in `rescue in log'
/Users/gdurelle/.rvm/gems/ruby-1.9.2-p290@dressmeNG/gems/activerecord-3.0.9/lib/active_record/connection_adapters/abstract_adapter.rb:199:in `log'
/Users/gdurelle/.rvm/gems/ruby-1.9.2-p290@dressmeNG/gems/activerecord-3.0.9/lib/active_record/connection_adapters/postgresql_adapter.rb:514:in `execute'
/Users/gdurelle/.rvm/gems/ruby-1.9.2-p290@dressmeNG/gems/activerecord-3.0.9/lib/active_record/connection_adapters/abstract/database_statements.rb:288:in `update_sql'
/Users/gdurelle/.rvm/gems/ruby-1.9.2-p290@dressmeNG/gems/activerecord-3.0.9/lib/active_record/connection_adapters/postgresql_adapter.rb:525:in `update_sql'
/Users/gdurelle/.rvm/gems/ruby-1.9.2-p290@dressmeNG/gems/activerecord-3.0.9/lib/active_record/connection_adapters/abstract/database_statements.rb:49:in `update'
/Users/gdurelle/.rvm/gems/ruby-1.9.2-p290@dressmeNG/gems/activerecord-3.0.9/lib/active_record/connection_adapters/abstract/query_cache.rb:16:in `update'
/Users/gdurelle/Sites/rails/DressMeNextGen/db/migrate/20110613125139_migrate_closets.rb:4:in `up'
/Users/gdurelle/.rvm/gems/ruby-1.9.2-p290@dressmeNG/gems/activerecord-3.0.9/lib/active_record/migration.rb:314:in `block in migrate'
/Users/gdurelle/.rvm/rubies/ruby-1.9.2-p290/lib/ruby/1.9.1/benchmark.rb:295:in `measure'
/Users/gdurelle/.rvm/gems/ruby-1.9.2-p290@dressmeNG/gems/activerecord-3.0.9/lib/active_record/migration.rb:314:in `migrate'

Answer 1

Here are a couple wild guesses that might help. Looks like you have a transaction aborting, being caught, and ignored somewhere; that can mess up the entire transaction the self.up runs in and that would explain your error message and the behavior you’re seeing.

The reset_column_information call usually goes after the database change and only if the schema has changed and you need to use the new schema for the rest of the migration; neither of these apply to you so you can drop Closet.reset_column_information completely.

You should also have an execute method available in your migrations so there’s no need to talk to the Closet at all. Also, you don’t need semicolons at the end of your SQL statements; they probably won’t hurt but if we strip this right down to the bare essentials we might make the problem go away.

Try this and see what happens:

def self.up
  say_with_time "Unifying gender column to h/f" do
    execute %q{UPDATE closets SET gender = 'h' WHERE gender IN ('homme', 'Homme', 'men', 'Men')}
    execute %q{UPDATE closets SET gender = 'f' WHERE gender IN ('femme', 'Femme', 'women', 'Women')}
  end
end

This gives us the bare minimum that we need to get your database updated. Hopefully the stray transaction problem went away with all the other stuff you didn’t need.