Added basic seed functionality #3
Conversation
There was a problem hiding this comment.
This looks great. Thank you so much for contributing as well as for correcting my clerical errors 😅
In terms of setting up a seed tracker, that is definitely an option and we can explore for a future PR. IMO, the utility of tracking seeds would be to be able to revert a seed run, so the problem gains a lot of scope. Open to thoughts, though!
|
No problem, always happy to contribute. About future seed features, I think it should probably be more along the lines of having the ability to run different seeds. Maybe these seeds would 'reset' the db before running, or just add the data. I don't think reverting a seed would be as useful as that. |
|
That's a good thought! My idea RE:reverting seeds was along the lines of being able to inject synthetic data and then remove only the synthetic data again, but I agree that is a pretty niche usage. I think the dead-simple approach would be to add support for a custom seed file name, and maybe equipping with a flag to optionally reset the db. I don't see a usage for tracking seeds in a table because seeding likely won't happen in prod. Tracking makes sense if we want the user to be able to select a seed file using a CLI (as well as viewing which seed is currently applied to the db), but that's a nice-to-have and maybe not worth an extra db table. We could also accomplish the same thing just by reading file names out of the directory, minus the ability to see which seed file is currently applied. Being able to select and "swap" a seed-state is neat, but could be accomplished with something like What do you think? |
2 participants
#2
Not sure if we want anything more complicated than an arbitrary sql file, I thought about making another table to keep track of seeds, similar to how migrations are tracked. If we do want, that let me know and I can update the PR.
Thanks!