Content
Migration
We’re squashing migrations because the old ones became unmaintainable.
Primary motivation is the change in acts_as_journalized, which renders
some old migrations moving wiki_versions into journals obsolete.
Secondary motivation is the abundance in migrations, clumsy inclusion of
seed data into migrations and rage from operations.
State of the Union
The different branches master (rails2) and feature/rails3 (rails3)
have diverged drastically. The point the divergence started is over a
year ago. Since then:
- Migrations were added to the rails2 branch.
- Migrations were added to the rails3 branch.
- Migrations were merged from the rails2 into the rails3 branch
- Migrations in the rails3 branch were made to work w/ ruby 1.9.3
- Migrations in the rails3 branch were made to work w/ rails 3.2
- Migrations in the rails3 branch were made to work with OpenProject 3.0.0.*
- Migrations from plugins were added to the rails3 branch w/ their original timestamps
- Migrations from plugins were added to the rails3 branch w/ new timestamps
The following things also apply:
- Migrations in the rails2 branch do not work with 1.9.3, but they work w/ 1.8.7
- Migrations in the rails3 branch do not work with 1.8.7, but they work w/ 1.9.3
- Migrations in the rails2 branch run fine until and including their HEAD.
- Migrations in the rails3 branch run fine until and including their HEAD.
Goal
What we want to acomplish:
- Migrations to OpenProject 1.9.3 from any state in the rails2 and rails3 branch can be run w/ 1.9.3
- Migrations to state in the rails2 branch that is not HEAD can be run w/ 1.8.3
- All migrations until a certain migration are squashed into one, not affecting the previoulsy run migrations in any instances.
Steps
Finding a point until which to squash migrations
The commit 1a26f29 has been identified to contain only migrations that both the rails2 and rails3 branch also contain. The rails2 and rails3 branch also only contain younger migrations than the youngest migration in 1a26f29. The youngest migration in 1a26f29 is:
20120319135006
Compare schema migrations from scratch to 20120319135006
Running the migrations from scratch to 20120319135006, revealed some issues with migration compatibility. This is the diff between the rails2 branch and the rails3 branch until the migration 20120319135006:
< # This file is auto-generated from the current state of the database. Instead of editing this file, < # please use the migrations feature of Active Record to incrementally modify your database, and < # then regenerate this schema definition. --- TextileConverterBlockquoteStart09339cab-f4f4-4739-85b0-d02ba1f342e6 # encoding: UTF-8 # This file is auto-generated from the current state of the database. Instead # of editing this file, please use the migrations feature of Active Record to # incrementally modify your database, and then regenerate this schema definition. TextileConverterBlockquoteEnd09339cab-f4f4-4739-85b0-d02ba1f342e6 5,7c6,9 < # Note that this schema.rb definition is the authoritative source for your database schema. If you need < # to create the application database on another system, you should be using db:schema:load, not running < # all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations --- TextileConverterBlockquoteStart09339cab-f4f4-4739-85b0-d02ba1f342e6 # Note that this schema.rb definition is the authoritative source for your # database schema. If you need to create the application database on another # system, you should be using db:schema:load, not running all the migrations # from scratch. The latter is a flawed and unsustainable approach (the more migrations TextileConverterBlockquoteEnd09339cab-f4f4-4739-85b0-d02ba1f342e6 113a116,118 TextileConverterBlockquoteStart09339cab-f4f4-4739-85b0-d02ba1f342e6 t.datetime "created_at", :null => false t.datetime "updated_at", :null => false t.string "name" TextileConverterBlockquoteEnd09339cab-f4f4-4739-85b0-d02ba1f342e6 116,118d120 < t.string "name" < t.datetime "created_at" < t.datetime "updated_at" 121c123,124 < add_index "custom_field_translations", ["custom_field_id"], :name => "index_f42a0c96f950276606abbd14403e71f580e91394" --- TextileConverterBlockquoteStart09339cab-f4f4-4739-85b0-d02ba1f342e6 add_index "custom_field_translations", ["custom_field_id"], :name => "index_custom_field_translations_on_custom_field_id" add_index "custom_field_translations", ["locale"], :name => "index_custom_field_translations_on_locale" TextileConverterBlockquoteEnd09339cab-f4f4-4739-85b0-d02ba1f342e6 379c382 < t.text "summary", :default => "" --- TextileConverterBlockquoteStart09339cab-f4f4-4739-85b0-d02ba1f342e6 t.text "summary" TextileConverterBlockquoteEnd09339cab-f4f4-4739-85b0-d02ba1f342e6
Next try was 20120319095930:
*** schema-old.rb Mon Aug 12 16:18:33 2013
--- schema.rb Mon Aug 12 16:34:07 2013
***************
*** 1,15 ****
! # This file is auto-generated from the current state of the database. Instead of editing this file,
! # please use the migrations feature of Active Record to incrementally modify your database, and
! # then regenerate this schema definition.
#
! # Note that this schema.rb definition is the authoritative source for your database schema. If you need
! # to create the application database on another system, you should be using db:schema:load, not running
! # all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended to check this file into your version control system.
ActiveRecord::Schema.define(:version => 20120319095930) do
create_table "attachments", :force => true do |t|
t.integer "container_id", :default => 0, :null => false
--- 1,17 ----
! # encoding: UTF-8
! # This file is auto-generated from the current state of the database. Instead
! # of editing this file, please use the migrations feature of Active Record to
! # incrementally modify your database, and then regenerate this schema definition.
#
! # Note that this schema.rb definition is the authoritative source for your
! # database schema. If you need to create the application database on another
! # system, you should be using db:schema:load, not running all the migrations
! # from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended to check this file into your version control system.
ActiveRecord::Schema.define(:version => 20120319095930) do
create_table "attachments", :force => true do |t|
t.integer "container_id", :default => 0, :null => false
***************
*** 362,378 ****
t.boolean "is_public", :default => true, :null => false
t.integer "parent_id"
t.datetime "created_on"
t.datetime "updated_on"
t.string "identifier"
t.integer "status", :default => 1, :null => false
t.integer "lft"
t.integer "rgt"
! t.text "summary", :default => ""
end
add_index "projects", ["lft"], :name => "index_projects_on_lft"
add_index "projects", ["rgt"], :name => "index_projects_on_rgt"
create_table "projects_trackers", :id => false, :force => true do |t|
t.integer "project_id", :default => 0, :null => false
t.integer "tracker_id", :default => 0, :null => false
--- 364,380 ----
t.boolean "is_public", :default => true, :null => false
t.integer "parent_id"
t.datetime "created_on"
t.datetime "updated_on"
t.string "identifier"
t.integer "status", :default => 1, :null => false
t.integer "lft"
t.integer "rgt"
! t.text "summary"
end
add_index "projects", ["lft"], :name => "index_projects_on_lft"
add_index "projects", ["rgt"], :name => "index_projects_on_rgt"
create_table "projects_trackers", :id => false, :force => true do |t|
t.integer "project_id", :default => 0, :null => false
t.integer "tracker_id", :default => 0, :null => false
***************
*** 385,400 ****
--- 387,403 ----
t.integer "project_id"
t.string "name", :default => "", :null => false
t.text "filters"
t.integer "user_id", :default => 0, :null => false
t.boolean "is_public", :default => false, :null => false
t.text "column_names"
t.text "sort_criteria"
t.string "group_by"
+ t.boolean "display_sums"
end
add_index "queries", ["project_id"], :name => "index_queries_on_project_id"
add_index "queries", ["user_id"], :name => "index_queries_on_user_id"
create_table "repositories", :force => true do |t|
t.integer "project_id", :default => 0, :null => false
t.string "url", :default => "", :null => false
Still no empty changeset. Try another old commit 69cbafa and version 20110729125454:
*** schema-old.rb Mon Aug 12 17:16:14 2013
--- schema.rb Mon Aug 12 17:21:26 2013
***************
*** 1,15 ****
! # This file is auto-generated from the current state of the database. Instead of editing this file,
! # please use the migrations feature of Active Record to incrementally modify your database, and
! # then regenerate this schema definition.
#
! # Note that this schema.rb definition is the authoritative source for your database schema. If you need
! # to create the application database on another system, you should be using db:schema:load, not running
! # all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended to check this file into your version control system.
ActiveRecord::Schema.define(:version => 20110729125454) do
create_table "attachments", :force => true do |t|
t.integer "container_id", :default => 0, :null => false
--- 1,17 ----
! # encoding: UTF-8
! # This file is auto-generated from the current state of the database. Instead
! # of editing this file, please use the migrations feature of Active Record to
! # incrementally modify your database, and then regenerate this schema definition.
#
! # Note that this schema.rb definition is the authoritative source for your
! # database schema. If you need to create the application database on another
! # system, you should be using db:schema:load, not running all the migrations
! # from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended to check this file into your version control system.
ActiveRecord::Schema.define(:version => 20110729125454) do
create_table "attachments", :force => true do |t|
t.integer "container_id", :default => 0, :null => false
***************
*** 362,378 ****
t.boolean "is_public", :default => true, :null => false
t.integer "parent_id"
t.datetime "created_on"
t.datetime "updated_on"
t.string "identifier"
t.integer "status", :default => 1, :null => false
t.integer "lft"
t.integer "rgt"
! t.text "summary", :default => ""
end
add_index "projects", ["lft"], :name => "index_projects_on_lft"
add_index "projects", ["rgt"], :name => "index_projects_on_rgt"
create_table "projects_trackers", :id => false, :force => true do |t|
t.integer "project_id", :default => 0, :null => false
t.integer "tracker_id", :default => 0, :null => false
--- 364,380 ----
t.boolean "is_public", :default => true, :null => false
t.integer "parent_id"
t.datetime "created_on"
t.datetime "updated_on"
t.string "identifier"
t.integer "status", :default => 1, :null => false
t.integer "lft"
t.integer "rgt"
! t.text "summary"
end
add_index "projects", ["lft"], :name => "index_projects_on_lft"
add_index "projects", ["rgt"], :name => "index_projects_on_rgt"
create_table "projects_trackers", :id => false, :force => true do |t|
t.integer "project_id", :default => 0, :null => false
t.integer "tracker_id", :default => 0, :null => false