I've gone into problem when my test db is using sqlite and I use postgres in prod
Sqlite doesn't have
inet attribute like postgres and I went into some old migration that I don't use anymore.
Clean up your old migrations with https://github.com/jalkoby/squasher
Easy your time on new envs + remove unneccessary create_table, drop_table migrations which happen all the time when we try to implement something
That gem seems super interesting. Haven't seen it before. Thanks for sharing!
I almost always recommend making sure you use the same database in development as you use in production. That way you don't get unexpected results when deploying.
How's that different from the schema.rb files ?
Is it compatible with Rails 5.0.x and forthcoming Rails 5.1?
Your migrations are just records of changes to the database but that doesn't mean it has recorded all changes to the database correctly (you can write broken migrations), so the schema.rb is actually a generated map of the actual database setup.
The schema is everything that the database currently contains has regardless of what your migrations say. Plus the schema is cached so you can keep track of it independently and use it for quicker setups of databases in development and test environments.
I don't think there's any migration related changes in 5.1, so if it works with 5.0 it should work with 5.1 no problem.
Thanks Chris for your answer.
I would have thought that the following command
rake db:schema:load (likely to be
rails db:schema:load in modern rails) could be used to quickly setup the database without having to run
rails db:migrate, but still preserving the usage of all migration features, especially the option to rollback to any point in time.
db:schema:load will load whatever is in the schema.rb file. You could have migrations that haven't been run yet and as such, they wouldn't show up in your schema or after a load.
Agree. but when testing or launching the app I should have an error about that, pushing me to run the few missing migrations.
After that, I will have a new and up-to-date
schema.rb which can be used for all deployment (unless I'm not testing before deploying...)
Yeah I think you're correct.
From the Rails guides:
In order to run your tests, your test database will need to have the current structure. The test helper checks whether your test database has any pending migrations. It will try to load your db/schema.rb or db/structure.sql into the test database. If migrations are still pending, an error will be raised. Usually this indicates that your schema is not fully migrated. Running the migrations against the development database (bin/rails db:migrate) will bring the schema up to date.
If there were modifications to existing migrations, the test database needs to be rebuilt. This can be done by executing bin/rails db:test:prepare.
Join 27,623+ developers who get early access to new screencasts, articles, guides, updates, and more.