Upgrade from 0.8.7 to 0.9.1: Unknown column 'editable' in 'field list': UPDATE `custom_fields` SET editable
Added by Glenn Gould almost 15 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 almost 15 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 almost 15 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 almost 15 years ago
Thanks for Guiding me to the Rails Migration, I'll dig into that to get a better understanding of the exact mechanisms.