Why's in Best Practices [rails migrations]

whys_in_best_practices.md

Why's in best practices

In software development there are loads of "Best practices" or suggestions what to do and what not in order to come to a better result.

For most of the cases you will be better of by just folowing these suggestions and for the rest it's very handy to understand why these suggestions exist.

Here is some explanation what I mean by handy to understand **why**

Never delete migrations - why?

Lets start with defining what are migrations.

Migrations are saved data/database structure changes over time.

They are there to allow you to recreate your database at any point in time. You should never delete one cause if you do so you will lose this capability.

The same might happen if you do one of the following:

• Reference application code inside migrations (Models, services and other app code changes over time and make the migration dependent on execution time.)

• Alter migrations after they have been applied

• Do data manipulation insdie migrations

Migrations in Rails

Rails comes with a handy feature called migrations that allowes you to easely create, apply, revert and track the state of migrations.

In real world projects this feature is not only used for migrations (database structure changes/DDL statements), but different other things where the charesteristics of rails migrations come to be handy. Like data changes and seeds.

One example of a rails migration that is not really a migration

class MigrateLocationsIds < ActiveRecord::Migration
  def change
    User.all.each do |user|
      user.location_ids&.each do |location_id|
        user.user_location.create!(location_id: location_id)
      end
    end
  end
end

1. It does not change the databaseAstructure
2. It referneces application code

So this already ignores pretty much everything a migration stands for. What will happen if we delete it?

$ rake db:migrate:status
           ...
   up     20170117162716  Create User
   up     20170118114002  Add headlin to user
   up     20170130152538  ********** NO FILE **********
   up     20170131112139  Rename rename headline to summary
          ...
$

Nothing - for databases where it was already applied it will show that the file is missing and for those where its not it just wont be there. And it still will be possible to travel through the DB structure changes if all other migrations actually are migrations.

Note

Don't take any best practices advice for granted - ask why and if the reason does not make sense just ignore it.

P.S. Tiger Woods is not actually a Tiger ;)