Upgrade from 0.8.7 to 0.9.1: Unknown column 'editable' in 'field list': UPDATE `custom_fields` SET editable

Added by Glenn Gould over 11 years ago

I'm trying to upgrade from 0.8.7 to 0.9.1, but I get an error during db:migrate and rake stops the migration:

Mysql::Error: Unknown column 'editable' in 'field list': UPDATE `custom_fields` SET editable = 0 WHERE ( (`custom_fields`.`type` = 'UserCustomField' ) )</italic>

That error, risen from db/migrate/103_set_custom_fields_editable.rb is correct, as there is indeed no column 'editable' available within the 'custom_fields' table, despite the fact that it should have been created by db/migrate/102_add_custom_fields_editable.rb. Creating the column manually with the mysql-client fixed that error:

ALTER TABLE custom_fields ADD editable BOOL DEFAULT true;

Maybe I'm paranoid, but the fact that db/migrate/102_add_custom_fields_editable.rb has neither risen an error, nor created the column 'editable' gives me the feeling, that there's a possibility it has never been executed. That would fit to the fact, that I had a custom definition 102_add_project_ui_theme.rb in the 0.8.7 installation. I've changed it's number to 999_add_project_ui_theme.rb and copied it to the 0.9.1 migration directory. After having created the 'editable' column manually, I've restared the migration. rake passes the 103* Script now, but stops at 999_add_project_ui_theme.rb, telling me that the column 'ui_theme' (which should be created by this script) inside the 'projects* table is already there (which is true, but shouldn't raise an error as far as I understand. Removing 999_add_project_ui_theme.rb allows me to finish migration. Is it possible, that there's something like a history or cache or environment setting that could cause rake to execute my old custom 102_add_project_ui_theme.rb script from 0.8.7 instead of the db/migrate/102_add_custom_fields_editable.rb or is it just coincidence and the initial error with the uncreated 'editable' column is related to something else?

  # 999_add_project_ui_theme.rb
  class AddProjectUiTheme < ActiveRecord::Migration
    def self.up
      add_column :projects, :ui_theme, :string
    end  
    def self.down
      remove_column :projects, :ui_theme
    end
  end
# trace output of migration
/redmine-0.9.1# RAILS_ENV=test rake --trace db:migrate
(in /redmine-0.9.1)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate
==  SetCustomFieldsEditable: migrating ========================================
rake aborted!
An error has occurred, all later migrations canceled:

Mysql::Error: Unknown column 'editable' in 'field list': UPDATE `custom_fields` SET editable = 0 WHERE ( (`custom_fields`.`type` = 'UserCustomField' ) )
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:219:in `log'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:323:in `execute'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:265:in `update_sql'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:338:in `update_sql'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:49:in `update_without_query_dirty'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:18:in `update'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/base.rb:847:in `update_all'
./db/migrate//103_set_custom_fields_editable.rb:3:in `up_without_benchmarks'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:282:in `send'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:282:in `migrate'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:282:in `migrate'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:365:in `__send__'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:365:in `migrate'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:486:in `migrate'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:562:in `call'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:562:in `ddl_transaction'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:485:in `migrate'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:472:in `each'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:472:in `migrate'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:400:in `up'
/redmine-0.9.1/vendor/rails/activerecord/lib/active_record/migration.rb:383:in `migrate'
/redmine-0.9.1/vendor/rails/railties/lib/tasks/databases.rake:116
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `call'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:636:in `execute'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `each'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:631:in `execute'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:597:in `invoke_with_call_chain'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:590:in `invoke_with_call_chain'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:583:in `invoke'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2051:in `invoke_task'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `each'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2029:in `top_level'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2023:in `top_level'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2001:in `run'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2068:in `standard_exception_handling'
/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1998:in `run'
/var/lib/gems/1.8/gems/rake-0.8.7/bin/rake:31
/var/lib/gems/1.8/bin/rake:19:in `load'
/var/lib/gems/1.8/bin/rake:19

Replies (3)

RE: Upgrade from 0.8.7 to 0.9.1: Unknown column 'editable' in 'field list': UPDATE `custom_fields` SET editable - Added by Glenn Gould over 11 years ago

After having watched the output of

script/about

I recognized a parameter: "Database schema version", which is set to 102 in my 0.8.7 - Installation.
Can anyone confirm, that this parameter functions in a way, that only scripts starting with numbers > current_version are executed during a db/migrate run?
That would explain the results I experienced...

Is there a recommended way for numbering .rb files for custom changes to the database scheme?

Thanks for your help ;-).

RE: Upgrade from 0.8.7 to 0.9.1: Unknown column 'editable' in 'field list': UPDATE `custom_fields` SET editable - Added by Jean-Philippe Lang over 11 years ago

You can learn more about Rails migration here:
http://api.rubyonrails.org/classes/ActiveRecord/Migration.html

And you're right, Redmine migration 102 was not executed because of your custom migration 102.
Although adding custom migrations in db/migrate is highly unrecommended, clashes should be very rare between core and custom migrations since migrations are now timestamped.

RE: Upgrade from 0.8.7 to 0.9.1: Unknown column 'editable' in 'field list': UPDATE `custom_fields` SET editable - Added by Glenn Gould over 11 years ago

Thanks for Guiding me to the Rails Migration, I'll dig into that to get a better understanding of the exact mechanisms.

(1-3/3)