Managing Database Structure Across Multiple Branches

The database layer of an app is a separate being and is controlled only by migrations. While creating new migrations, remember to make the planned transformation of a database structure reversible. Of course, in extreme cases, we can raise IrreversibleMigration no down method. This will also inform nós about the fact that the migration cannot be reversed. There are different types of changes that we make in the migration – creating, modifying and removing tables, columns or indexes. Deleting and modifying operations are the most sensitive to change. Why? Let’s consider the following scenario:We are working with the master branch, which is our main working path. Currently we have one table:

 class CreateArticles < ActiveRecord::Migration
   def change
     create_table :articles do |t|
       t.string :name
       t.text :description
       t.string :status, null: false
       t.timestamps null: false
     end
   end
 end

O nosso Article model has such validations which require the presence of nome, description e estatuto attributes.

 class Article < ActiveRecord::Base
   validates :name, presence: true
   validates :description, presence: true
   validates :status, presence: true
 end

We are implementing changes into our artigos table on feature development branch and we delete the estatuto column.

 class RemoveStatusColumnFromArticles < ActiveRecord::Migration
   def change
     remove_column :articles, :status, :string
   end
 end

We execute the migration:

 $ [example/feature]: bundle exec rake db:migrate
 == 20150605120955 RemoveStatusColumnFromArticles: migrating ===================
 -- remove_column(:articles, :status, :string)
   -> 0.0717s
 == 20150605120955 RemoveStatusColumnFromArticles: migrated (0.0718s) ==========

The schema for a database changes:

diff --git a/db/schema.rb b/db/schema.rb
index 2a100a9..76438c1 100644 --- a/db/schema.rb +++ b/db/schema.rb @@ -11,14 +11,13 @@ #

It's strongly recommended that you check this file into your version control system.

-ActiveRecord::Schema.define(version: 20150605120350) do
+ActiveRecord::Schema.define(version: 20150605120955) do
  createtable "articles", force: :cascade do |t|
    t.string   "name"
    t.text     "description"
-    t.string   "status",      null: false     t.datetime "createdat",  null: false
    t.datetime "updated_at",  null: false
  end

end

Next, we commit the changes to the feature branch. To simulate this issue we switch the current branch to master. The base structure was changed by migration, which deletes the estatuto column on the feature branch. Let’s try to use the following command:

Article.create!(name: "Kaboom", description: "Lorem ipsum...", status: "active")

What will happen after executing the above mentioned código? The error: ActiveRecord::UnknownAttributeError: unknown attribute 'status' for Article will be raised and that’s because of the incompatible structure version of a database. Before changing the branch to master we should roll back the a migration that deletes the estatuto column from the Article table.

What can we do in order to check if we have to roll back some migrations before switching the branches? With the use of the version control system (here it is git) we can check our work by creating a helpful alias:

 ~/.gitconfig
 [alias]
  migrations = "!f() { git diff --name-only $1..$2 db/migrate | tr -d '[A-Za-z/_.]'; }; f"

Executing the git migrations master feature command will result in the list of migration versions, which are located on feature branches, and which cannot be found on master.

 $ [example/feature]: git migrations master feature
 20150605120955

Thanks to this information we can easily roll back the changes done in the database structure before switching to master.

 $ [example/feature]: bundle exec rake db:migrate:down VERSION=20150605120955
 == 20150605120955 RemoveStatusColumnFromArticles: reverting ===================
 -- add_column(:articles, :status, :string)
   -> 0.0009s
 == 20150605120955 RemoveStatusColumnFromArticles: reverted (0.0045s) ==========

One more thing that we should do after rolling back the migration is to restore the status of a database schema.

$ [example/feature]: git status
On branch feature
Changes not staged for commit:
 (use "git add ..." to update what will be committed)
 (use "git checkout -- ..." to discard changes in working directory)

modified:   db/schema.rb

no changes added to commit (use "git add" and/or "git commit -a")
$ [example/feature]: git checkout db/schema.rb
$ [example/feature]: git status
On branch feature
nothing to commit, working directory clean

Now we can easily switch to the master branch.

The given example is not a complicated problem to solve but it should help you realize how important it is to maintain the structure of a database during the change in the work context.