jbk1ba
Last Updated: February 25, 2016
·
1.339K
· unframework
1482da5061ef7fdfb6b1fdc8d368a2f5

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.

Say Thanks
Respond

1 Response
Add your response

17580
None

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

over 1 year ago ·