Migrations are a feature of Active Record that allows you to evolve your database schema over time.
They use a Ruby DSL so that you don't have to write SQL by hand, allowing your schema and changes to be database independent.Before this migration is run, there will be no table. Active Record knows how to reverse this migration as well: if we roll this migration back, it will remove the table.On databases that support transactions with statements that change the schema, migrations are wrapped in a transaction.If the database does not support this then when a migration fails the parts of it that succeeded will not be rolled back.You will have to rollback the changes that were made by hand., that is to say a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration.You can think of each migration as being a new 'version' of the database.
A schema starts off with nothing in it, and each migration modifies it to add or remove tables, columns, or entries.
Active Record knows how to update your schema along this timeline, bringing it from whatever point it is in the history to the latest version. These special columns are automatically managed by Active Record if they exist.
Note that we define the change that we want to happen moving forward in time.
The name of the migration class (Camel Cased version) should match the latter part of the file name. Rails uses this timestamp to determine which migration should be run and in what order, so if you're copying a migration from another application or generate a file yourself, be aware of its position in the order.
Of course, calculating timestamps is no fun, so Active Record provides a generator to handle making it for you: The model and scaffold generators will create migrations appropriate for adding a new model.
This migration will already contain instructions for creating the relevant table.