I’m a big fan of doing things The Rails Way.
erb as the templating language.
minitest instead of reaching for
Using ActiveRecord fixtures instead of employing the
This is not an indictment of the alternative solutions. They have their place, and competition drives innovation. But I’ve found leaning hard into convention over configuration has continued to pay dividends, so I’m going to keep investing.
ActiveRecord fixtures are typically associated with testing.
But there’s a command to load them into any environment…
RAILS_ENV=development bin/rails db:fixtures:load
This will take the test data and shove it into the development environment.
The Rails convention for loading default data into the environment is
This command loads the environment, and executes the file
I like the ideal of
bin/rails db:seed being a command you run one time when setting up a project.
If it’s ever being invoked again, it means that I’m wanting to start over from ground zero.
Building on this opinion of the world, this is what a typical
db/seeds.rb file looks like in one of my Rails projects.
return true if ENV["CONFIRM_FIXTURE_LOAD"]
Loading fixtures into the database will clobber all existing data in the tables.
To confirm this is what you want to do, set the environment variable CONFIRM_FIXTURE_LOAD
$ CONFIRM_FIXTURE_LOAD=yeppers bin/rails db:seed
load_fixtures if confirmed?
Now you can have your cake and eat it to. Where your cake is your test environment. And eating it is your development environment.
I like this for a few reasons.
bin/rails db:fixture:load lacks, wrapping it with confirmation communicates the downside to the future self.
bin/rails db:seed should be for setting up a project, not migrating over time.
There is a downside.
YAML can be a real pain point when dealing with lots of data, complex associations, join tables, etc. I’ve got some strategies for overcoming that downside, but that’s another post.