Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

rake db:schema:load vs. migrations

Very simple question here - if migrations can get slow and cumbersome as an app gets more complex and if we have the much cleaner rake db:schema:load to call instead, why do migrations exist at all?

If the answer to the above is that migrations are used for version control (a stepwise record of changes to the database), then as an app gets more complex and rake db:schema:load is used more instead, do they continue to maintain their primary function?


Caution:

From the answers to this question: rake db:schema:load will delete data on a production server so be careful when using it.

like image 468
sscirrus Avatar asked May 05 '11 23:05

sscirrus


People also ask

What does rake db migrate do?

A migration means that you move from the current version to a newer version (as is said in the first answer). Using rake db:migrate you can apply any new changes to your schema. But if you want to rollback to a previous migration you can use rake db:rollback to nullify your new changes if they are incorrectly defined.

What does schema load do?

rake db:schema:load is great for the first time you put a system in production. After that you should run migrations normally. This also helps you cleaning your migrations whenever you like, since the schema has all the information to put other machines in production even when you cleaned up your migrations.

What is rake db?

#rails #database. Rake is a utility built into Ruby and Rails, which provides an efficient way for managing database changes. You can easily migrate database changes to servers by only using a command line!

What rails db Migrate?

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".


2 Answers

Migrations provide forward and backward step changes to the database. In a production environment, incremental changes must be made to the database during deploys: migrations provide this functionality with a rollback failsafe. If you run rake db:schema:load on a production server, you'll end up deleting all your production data. This is a dangerous habit to get into.

That being said, I believe it is a decent practice to occasionally "collapse" migrations. This entails deleting old migrations, replacing them with a single migration (very similar to your schema.rb file) and updating the schema_migrations table to reflect this change. Be very careful when doing this! You can easily delete your production data if you aren't careful.

As a side note, I strongly believe that you should never put data creation in the migration files. The seed.rb file can be used for this, or custom rake or deploy tasks. Putting this into migration files mixes your database schema specification with your data specification and can lead to conflicts when running migration files.

like image 113
jesse reiss Avatar answered Oct 12 '22 23:10

jesse reiss


Just stumbled across this post, that was long ago and didn't see the answer I was expecting.

rake db:schema:load is great for the first time you put a system in production. After that you should run migrations normally.

This also helps you cleaning your migrations whenever you like, since the schema has all the information to put other machines in production even when you cleaned up your migrations.

like image 28
ereslibre Avatar answered Oct 13 '22 00:10

ereslibre