Concept Of Data Migrations in Ruby on Rails

Every now and then we need to change actual data in the production database. The first  thing that’ll comes to your mind is Rails migration, Rails Migration basically helps Ruby to define changes to your database schema and making it possible to keep all the things synchronized with the actual code.Rails migrations can only make schema changes and not the actual data which is there in the database.

What Can Rails Migration Do?

create_table(name, options)
drop_table(name)
rename_table(old_name, new_name)
add_column(table_name, column_name, type, options)
rename_column(table_name, column_name, new_column_name)
change_column(table_name, column_name, type, options)
remove_column(table_name, column_name)
add_index(table_name, column_name, index_type)
remove_index(table_name, column_name)

Migrations support all the basic data types − like ,string,text,integer,float,datetime and timestamp,binary,Boolean

The activities done by Rails Migration can only be done using any front-end GUI or directly on SQL prompt.
But manupulating data in migrations is a bad idea for a few reasons. For one, data migrations files will always going to stays stays in the db/migrate directory for posterity whenever a new ruby on rails developers sets his local development environment. This is not very secure. For example, future changes to a class and its logic can easily break the migration later on.

A second issue is that those data migrations might be ignored by future developers i mean if instead of running rake db:migrate the developers run rake by using db:schema:load or rake db:reset. Both of these commands hardly going to load the current version of the database structure using the schema.rb file without touching the migrations.

A third issue with that is your application deployment is now totally going to be dependent on the data migration process to be completed first. This is actually not a big problem when you know your application is new and your database is small, But what about large databases that having millions of records? Then Your deployment will now have to wait for the data manipulation to be finished first and that thing is just asking for trouble, with possible hanging or failed migrations.

Here I would like you to suggest a slightly better alternative of using temporary rake tasks. We all know temporary rake tasks basically allows us to decouple a deployment from completed migrations and  it also gives us the more control of the data manipulation process by encapsulating it in single place. But The downside of this thing is that we need to remember either to add this particular rake task to our deployment script or run the rake task manually after deployment. We will also need to clean up and remove the temporary rake task once the changes have been deployed and implemented.