According to Rails doc: http://guides.rubyonrails.org/migrations.html
"Active Record tracks which migrations have already been run so all you have to do is update your source and run rake db:migrate."
How does ActiveRecord actually do this? Where does Active Record store the data?
I suspect this might be stored in the database itself? In a table somewhere.
On my development machine, I ran all the migrations. Then I copied the production database over using mysqldump. Then I ran "rake db:migrate:status", it shows correctly the migrations that need to run on the production database.
I used to think that ActiveRecord keeps track of the last migration run using the timestamp. But I think this is not true because ActiveRecord correctly runs the "older" migrations merged in from another code branch.
Could someone with inside knowledge of this elaborate? Thanks
timestamps was added to the migration by Rails and it added the columns created_at and updated_at to the events table. These special columns are used by Rails to keep track of when a record is created and updated.
Rails Migration allows you to use Ruby to define changes to your database schema, making it possible to use a version control system to keep things synchronized with the actual code. Teams of developers − If one person makes a schema change, the other developers just need to update, and run "rake migrate".
A Rails migration is a tool for changing an application's database schema. Instead of managing SQL scripts, you define database changes in a domain-specific language (DSL). The code is database-independent, so you can easily move your app to a new platform.
You can append as many column name/type pairs as you want. By default, the generated migration will include t. timestamps (which creates the updated_at and created_at columns that are automatically populated by Active Record).
Rails creates a table in your database called schema_migrations
to keep track of which migrations have run.
The table contains a single column, version
. When Rails runs a migration, it takes the leading digits in the migration's file name and inserts a row for that "version", indicating it has been run. If you roll back that migration, Rails will delete the corresponding row from schema_migrations
.
For example, running a migration file named 20120620193144_create_users.rb
will insert a new row with a version of 20120620193144
into the schema_migrations
table.
You are free at any point to introduce migrations with earlier versions. Rails will always run any new migrations for which there is not a corresponding row in schema_migrations
. The leading digits don't have to be a timestamp, you could call your migration 001_blah.rb
. Earlier versions of Rails used this format, and used sequential numbering for newly generated migrations. Later versions have switched to timestamps to help prevent multiple developers from independently generating migrations with the same number.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With