Open timelf123 opened 8 years ago
@timelf123 We actually manage this as a separate package that allows us to run migration scripts at server launch.
Part of the problem I see here is that the seed data need to be idempotent or you'd just add data every time the server restarted. Our migrations are coded to check if they've already performed their work and just return if they have.
In fact, in production this would run code for each worker, we had to use an npm package mongoose-mutex
to ensure that only one worker was running a migration at a time.
I agree that general data migration functionality would be helpful. Though I believe it may be best to start as a module.
Also this should record what was run, and when, and the result, very similar to larvel's migrations: https://laravel.com/docs/5.3/migrations
This includes its own collection migrations
that stores the results, so a migration is checked against it's run history, and the migration "type" of:
I'm all in on the module idea. @ADSKLowenthal when you have some time would you mind spearheading the initial repo creation and getting something going?
@timelf123 Sure, might not be till the weekend. We do have a migrations module we use. It's not nearly as robust, but could be a good starting point. @vtdave @rjVapes Do we think this is something from scratch, or should we consider putting our migrations module through OSSA?
@clowenhg no rush, and if it works that's even more than I was hoping for. Just looking for a place to start hacking ;)
Either with an env variable and JSON seed file (more flexible, can touch multiple collections), or a more simple one collection check. Example for a package called packageName, this code will run a seed function only if the collection does not exist