-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migration/planning element data to work packages #443
Migration/planning element data to work packages #443
Conversation
The migration fails on my machine:
I guess we talked about something similar before: You told me that Postgres does not update the primary key counter on certain occasions. |
There was a problem noted by Travis: /home/travis/build/opf/openproject/db/migrate/20130917131710_planning_element_data_to_work_packages.rb:49:in `add_planning_elements_to_work_packages' /home/travis/build/opf/openproject/db/migrate/20130917131710_planning_element_data_to_work_packages.rb:17:in `block in up' /home/travis/build/opf/openproject/db/migrate/20130917131710_planning_element_data_to_work_packages.rb:314:in `block (2 levels) in say_with_time' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:446:in `suppress_messages' /home/travis/build/opf/openproject/db/migrate/20130917131710_planning_element_data_to_work_packages.rb:313:in `block in say_with_time' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:438:in `block in say_with_time' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:438:in `say_with_time' /home/travis/build/opf/openproject/db/migrate/20130917131710_planning_element_data_to_work_packages.rb:312:in `say_with_time' /home/travis/build/opf/openproject/db/migrate/20130917131710_planning_element_data_to_work_packages.rb:16:in `up' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:410:in `block (2 levels) in migrate' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:410:in `block in migrate' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/connection_adapters/abstract/connection_pool.rb:129:in `with_connection' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:389:in `migrate' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:528:in `migrate' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:720:in `block (2 levels) in migrate' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:777:in `call' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:777:in `ddl_transaction' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:719:in `block in migrate' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:700:in `each' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:700:in `migrate' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:570:in `up' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/migration.rb:551:in `migrate' /home/travis/build/opf/openproject/vendor/bundle/ruby/1.9.1/gems/activerecord-3.2.14/lib/active_record/railties/databases.rake:193:in `block (2 levels) in <top (required)>' /home/travis/build/opf/openproject/lib/tasks/ci.rake:77:in `block (3 levels) in <top (required)>' This occurs when running the migration on an empty db. Will have to check for that. |
I added a safeguard to check for whether there are legacy planning elements to migrate. So this should be fixed. The bug caused by a falsely set primary key sequence stems from the dump we are using where postgres gets it wrong. So that shouldn't be an issue on production databases. |
OP ticket: https://www.openproject.org/issues/1979