Reaction: Move to a non-Meteor migrations solution
Proposed Work
This would be a first stage. Eventually we will want to move this out of the app entirely to an NPM package / CLI.
- Remove the Meteor percolate:migrations package and add this NPM package, which has the same API: https://github.com/emmanuelbuah/mgdb-migrator
- Change the imports to come from the NPM package.
- Minor changes to the
config, primarily to add the db connection string, which we should be able to get fromprocess.env.MONGO_URL - Rewrite all the migrations so that they do not import or use any Meteor code. Also make all of the
upanddownfunctionsasync.
This can also fix https://github.com/reactioncommerce/reaction/issues/3037 by setting the latest version as the current version in the DB as part of initial fixture import.
See also some discussion here: https://github.com/reactioncommerce/reaction/issues/4362
aldeed
All 9 comments
I am going to put in my .02 and say we should bite the bullet now and migrate to a real grown-up migrations package. We could keep percolate in for now and just use the new one going forward.
zenweasel
on 11 Jul 2018
Also make all of the
upanddownfunctionsasync
The migrations should run synchronously and sequentially as they might depend on one another. We also want a blocking error if one were to fail so that the migration process stops and the operator can fix the problem before subsequent migrations run. Will this be the case with async?
ticean
on 11 Jul 2018
Spoke to @spencern and my team will take on researching a package and proposing/putting together a solution. But all feedback is helpful.
zenweasel
on 11 Jul 2018
I researched on this and node-migrate seems like a good choice
- It has a command line tool to run the migrations.
- I couldn't see any open issue that would be a deal-breaker for us.
- Weekly downloads -> 5,848
I am going to start coding since even if we decide to switch to another lib the migrations code is going to be almost the same.
Akarshit
on 12 Jul 2018
I'm fine with node-migrate, too. I like it better for the long term. But everything in this issue will still have to be done before/during switching to that package, which is why I thought this could be an interim step. Either way.
@ticean, the mgdb-migrator migrator package requires that up/down return Promise, so that's why they'd all need to be async. The word "async" is confusing, but that's actually how it _ensures_ that each migration is finished before it begins the next one. That's how it ensures that it is NOT still doing anything async. But the important part that I didn't mention is that the migration functions must also await everything they call that is async.
aldeed
on 12 Jul 2018
I am currently not working on this for now, busy with other stuff right now.
If someone wants to grab this, just post a comment and we can discuss.
Akarshit
on 1 Aug 2018
Taking over this to get a quick solution in place for 2.0
aldeed
on 4 Sep 2018
We will do this in 2.1. Removing from 2.0 epic
aldeed
on 16 Sep 2018
Related issues
aldeed
路
4Comments
ajporlante
路
4Comments
mikemurray
路
4Comments
nnnnat
路
4Comments
Eduard-Hasa
路
4Comments
Most helpful comment
I'm fine with
node-migrate, too. I like it better for the long term. But everything in this issue will still have to be done before/during switching to that package, which is why I thought this could be an interim step. Either way.@ticean, the
mgdb-migratormigrator package requires that up/down return Promise, so that's why they'd all need to beasync. The word "async" is confusing, but that's actually how it _ensures_ that each migration is finished before it begins the next one. That's how it ensures that it is NOT still doing anything async. But the important part that I didn't mention is that the migration functions must alsoawaiteverything they call that is async.