MaMpf-HD
Null migration / Zero migration
Our list of DB migrations has become incredibly long over the years. We might discuss cleaning it up a little by creating a null migration, see e.g. here, from which we can then move on freshly. There is also a gem for that called squasher.
On the other hand, this kind of destroys history, so it might not be a good idea. Also, as is written in the docs of the squasher gem
If an old migration inserted data (created ActiveRecord model records) you will lose this code in the squashed migration
I am kind of torn on that topic, maybe more against than for it, but I wanted to put it up for discussion anyway. Note that our current first migration comes from a null migration I manually created many years ago.
This is not important for production as we always start with an already-existing state and only run new migrations. However, for development, it might be a good idea to squash some migrations together such that we don't get any errors related to old gems that were used in the migrations.
I'm just wondering right now why I posted this comment in #665:
For development, instead of seeding, we restore a sample database and then still use migrations. For testing, we continue to use db seeding.
Since in #652, I've tried to also restore the dev state directly from the schema file. I guess there was a problem with doing this and at the same time using the pre-seed which essentially constructs the database from scratch, so that's why we use bundle exec rails db:migrate when pre-seeds are used, but bundle exec rails db:schema:load for tests. Also see this Rails comment.
Maybe you possibly meant that we do not use Rails' built-in seeding process that uses a seed file db/seeds.rb and then rails db:seed but the process of restoring a sample database and the running the migrations from that point on.
By the way, my above comment is quite outdated. I remember that we discussed this topic in Basecamp and in our meetings and I am now definitely pro null-migration.