Ask A Question

Notifications

You’re not receiving notifications from this thread.

Just sharing: Squash your migrations

Roman Storm asked in General

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.
So,
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

Reply

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.

Reply

2 questions:
How's that different from the schema.rb files ?
Is it compatible with Rails 5.0.x and forthcoming Rails 5.1?

Reply

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.

Reply

Thanks Chris for your answer.
I would have thought that the following command rake db:schema:load (likely to berails db:schema:load in modern rails) could be used to quickly setup the database without having to runrails db:migrate, but still preserving the usage of all migration features, especially the option to rollback to any point in time.

Reply

Yeah, 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.

Reply

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

Reply

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.

Reply
Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 82,329+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.