Put seed DB data in a migration
RelayRobin is a deployable product, but most websites deal with a similar issue: during deployment, some basic initial data has to be seeded into the database. For example, a starting sample account to login with, some bootstrap defaults, etc.
We used to deal with that by having a seed SQL file that would auto-run on install. With judicious use of INSERT IGNORE, we could allow this file to be re-run multiple times with impunity, for added safety.
But as schema changed and evolved, this created headaches. Renaming a column would mean that not just code had to be changed, but also the SQL file. And because this script would run only on initial deploy, it was a pain to test, and we caught bugs caused by forgetting to update it as late as release testing instead of before even merging to master.
So, we just created a DB migration (we use Phinx) that put all of the seed data into the DB once and for all, and ditched the SQL init file. Now, when we add a new column or rename/reformat an existing one, seed data is seamlessly updated as part of the entire dataset. One less piece of code to worry about.
Caveat emptor: we still kept the INSERT IGNORE to avoid errors for older installs; also, we made the seed data IDs well-known and hardcoded, so that we can apply some special treatment just to the seed records down the line, if need be.
Written by Nick Matantsev
Related protips
2 Responses
How do you handle seed data for new tables?
For example, if my application is already in Production and I run the migrations, I wouldn't want seed data to be added (it might be visible to users).
@mattbostoc don't know if you'll see this. But you shouldn't be using seeders on production, they're for test data only. Migrations are what you should be using for one way data changes, structure or content. You can read in more detail about it in the phinx docs
