We can’t simply use a seeds file because don’t know all the vendors beforehand. We might onboard new ones every couple weeks. So our options are:
Option One:
- Push out new code (a new module dedicated to handling the vendor-specific logic).
- Manually log in to our admin portal and create a new vendor record with the proper slug ID (so that the dynamic dispatch can resolve correctly to the new vendor module) OR have shell access to the server to run a prepared seed file.
Pros: no migration required
Cons: manual, prone to human errors (misspellings etc) OR it requires shell access to server.
Option Two:
- Push out new code (a new module dedicated to handling the vendor-specific logic).
- Include a migration that adds the proper record to the vendors table.
Pros: automated, exact.
Cons: ???
Keep in mind that in this simplified example, the “vendors” table is very narrow: it’s almost just a key/value store.
Enums
Another use case where “seed migrations” make sense: we have stopped using enums in our database columns because they don’t play nice with migrations. Some divisions “solve” this problem by letting the application restrict the column values. That causes headaches for BI because when they are doing any reporting on those databases, they have to crack open the application code to know what the allowable values are, e.g. status_id 1 means “active” and status_id 13 means “cancelled” etc. And god forbid you accidentally let a bad value in. It’s very opaque, there are no constraints inside the database, and you experience something akin to “vendor lock” with your application code so that even if you wanted to replace the application that sits on top of that database, you’d be stuck coding in the same ad-hoc ersatz enums somewhere inside the application. Boo.
So instead of using enums in the database, we create a dedicated table, e.g. “statuses” and then reference it via a foreign key (I know, it’s hardly revolutionary). It’s more work to set up, but it makes things more transparent for BI/reporting and it plays nice with migrations.
And that seems like a really good use-case for using a migration instead of a seed: the application code has specific logic built around those statuses. The application falls apart if you don’t have specific values in your database. And importantly, when you need to add a new status along with new behavior, a migration seems like a really clean way to introduce that change. Importantly if the enum columns played nice with migrations, then you’d modify the allowed values via a migration anyhow.
If you think of migrations as strictly defining database structure, that solution might annoy you, but if you think of migrations as managed database changes, it seems like a pretty viable solution.
