Menu
I've just really started with Ruby and Rails, and one of the things that I find myself really enjoying is the conventions it makes you use.
I want to mimic that behavior in my own non-Ruby projects.
My question is how does it actually work? I know I can look through the Rails code, but I'm not that far enough in my understanding to know what's going on in it.
I know that it takes a baseline script and then runs update schema changes against it. But how does it know what version it's on? How would I mimic that in another framework / database?
349
rake db:migrate makes changes to the existing schema. Its like creating versions of schema. db:migrate will look in db/migrate/ for any ruby files and execute the migrations that aren't run yet starting with the oldest.
rake db:migrate is the script where db is the namespace and migrate is the task name defined. So bundle exec rake db:migrate executes the rake script with the command db:migrate in the context of the current bundle.
down. The down command executes the migrations of your currently configured migrations directory. More specific the down migrations are being called. Down migrations are called in reverse order in which the up migrations previously were executed.
Unlike rake db:migrate that runs migrations that have not run yet, rake db:schema:load loads the schema that is already generated in db/schema. rb into the database. Always use this command when: You run the application for the first time.
Note: This is true so far as Rails 2.x. It may not hold true for rails 3, as I haven't spent as much time with Rails 3 as I would have liked.
Rails creates a special hidden table named schema_migrations. This table has a single column named version. And there is a row in this column for every migration you have. The value being the timestamp that matches the migrations filename timestamp.
When you migrate, it looks through all your migrations in chronological order (also happens to be alphabetical order due to the timstamp based naming convention). For every migration it looks for a matching row in the schema_migrations table. If it fails to find one, then it runs that migration, and adds the timestamp the table. If it does find one, it assumes it already ran and simply skips it.
The result is that 2 developers can both commit migrations in any order, and it's fine. This is because Rails knows exactly what migrations have been run and which haven't, regardless of when your database first saw them.
So to do something yourself like this, you simply need a way to permanently store this state about which steps been taken and which have not.
79
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
