Open inform880 opened 6 months ago
inform880
commented
6 months ago 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.
ibrahidm
commented
6 months ago 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 postgrate seed state1.sql --reset. A CLI select menu would just be UI-sugar.
What do you think?
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!