Setting up Active Record Migrations with Active Record.

Active Record is go to ORM for making database and model connections easier to create, manage, and use.

One Command, Many Details

When using the Active Record Gem, there are many built-in tools that make a developers life just a little bit easier. The feature I currently love the most is the create migration command.

By typing in the following command, a migration file is created for management of the database via a “create” class that inherits from Active Record Migration.

bundle exec rake db:create_migration NAME=database_name

This migration includes the creation of a table (of student names and grade levels) used to seed data and also as a template for the addition of new students when using a POST to the Application Controller.

Adding More Migrations and Models

The wonderful part of using this process to make your migrations and models is that adding more databases is just as easy as adding the first. By calling the same terminal command (with a different database name) the user can once again automatically set up a migration file and associated model file.

On additional value of this process is that the migration file naming system includes a date based convention that helps manage the sequence in which the migrations run. This ensures that as you add multiple migrations for one or many different databases, they are always populated in the same, consistent order as the “first” or oldest migration is always run first and sequentially based on the date value.

Making Changes to Databases - Migrations that Change Databases

Until now, each of these migration commands were based around creating NEW databases. Using Active Record to modify these databases is also just as easy. With a slight modification to the terminal command, a new migration will be created, but no additional model will be created.

bundle exec rake db:create_migration NAME=add_new_item_to_db 

While technically there is nothing different with this migration creation, the naming nomenclature is where there is significant value. With the date included in the name, it will ensure that this update will always run AFTER the original database is created.

Now that this migration is created, you will need to run the migration with the command below.

bundle exec db:migrate

This will add the migration without re-running the previously run migrations (the original database creations).

It is also possible to undo a modification without a complete re-re write of the original migration. Using the “rollback” database terminal command, the developer can essentially “un-migrate” the latest migration.

bundle exec rake db:rollback

This merely removes the changes made by the newest migration without actually deleting the migration. Thus, if that change needs to be re-instituted, it is as simple as running the migration terminal command again and the change is added again.

---

BONUS - Why not change the original database with the updates?

There are a few considerations you would want to make, both of which come down to broader considerations and best practice.

When collaborating on a project, any changes you make in your local environment will not be reflected on any other versions of the application.

This means that if you want to change a database, it would be most appropriate to add a new migration so that it is easier to integrate into future version and also so that the base functionality, where earlier versions of your app are being used, are not changed when you commit your changes.

This also holds true with rollback of a migration. With the same considerations above regarding changing the original database, rolling back a feature after it is shared would also be bad practice as it would modify the database structure on which others are working.

The general rule is… adding is okay, removing is not.

---