Migrate down from CLI

[slonoed]

Can I do it?

[emirotin]

Now, it's mentioned in the rollback documentation: https://github.com/emirotin/mongodb-migrations#migratorrollback

The reason is the rollback is intended for undoing recent migrations set, and it's only known after applying the set of migrations and storing them in the Migrator object.

Though I may allow running individual migrations from the CLI some day.

[victorbstan]

If there's a "down" definition defined, then why can't the CLI run that part only? The down definition should have all that a migration needs to apply for a rollback... IMHO

[emirotin]

The library as it is doesn't support running individual migrations from the CLI.

With the CLI usage you run everything that wasn't ran before. WIth the Migrator object (programmatic usage) you can add migrations by hand.

The rollback procedure is meant to undo everything from the current attempt. With the programmatic usage the list of the current attempt is available and hence the rollback is possible (as I explained in the previous answer).

The CLI is stateless - it doesn't know what have just happened on the previous run.

Again as already mentioned I may add the ability to manually run individual transactions from the CLI with optional up/down parameter.

Can you elaborate on your use-case? Do you run your migrations by hand and then want to rollback them by hand as well? Do you need this functionality for the development error/trial, like write the migration, run, check, rollback, iterate?

[victorbstan]

For the last couple of questions, yes and yes. But not only for dev, if this functionality (manual rollback) exists for dev, I imagine it should work for any environment. Have you looked at how migrations work in other frameworks like Rails/Django/etc? This is quite a common/standard way to handle migrations. Rolling back the latest migration, which would simply be the same as migrating up, but using the 'down' definition in the migration script. More complex systems allow for providing a number of migrations to rollback, or the ID of the migration to rollback up-to, if that makes sense...

[emirotin]

So as I explained above this tool while used from the CLI is "run everything that's missing"
Thus it's unclear how the unparameterized rollback would work.

Instead I will simply add an ability to run individual migrations (or multiple in order) up and down. Not sure how fast this can be down given I'm slightly off from Mongo development recently.
But will try to do so during my upcoming vacation.

[eremzeit]

I second @victorbstan's request. Not being able to rollback from the command-line is a deal-breaker to me.

Here's a use case for using down migrations by hand. I create a feature branch that renames a collection. Later I need to switch back to master branch and hot fix something. In this case, I would want to rollback the migration made on the feature branch so that I can even run the code on master branch again (which is necessary because both branches ultimately would be used with the same dev database). Of course, some migrations can't be rolled back and other migration frameworks have a way of specifying this in the migration file.

Otherwise nice library though.

[emirotin]

Fair enough. I have this feature planned, just didn't have time to implement it yet. But plan to find some soon.

[tjaartvdwalt]

Great project. I particularly like being able to set config in js/coffeescript instead of json, since this leads to duplicated config for me.

+1 on being able to manually undo migrations.

[emirotin]

Thanks
I really understand this need. The problem is I stopped using MongoDB for
my projects and since then didn't actively maintain the library.
I hope to find time and return to it.

On Wed, Mar 23, 2016 at 7:35 PM Tjaart van der Walt <
notifications@github.com> wrote:

Great project. I particularly like being able to set config in
js/coffeescript instead of json, since this leads to duplicated config for
me.

+1 on being able to manually undo migrations.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#8 (comment)

[kryz81]

+1. Your project is great and easy to configure, but a "rollback" function to a specific migration is really needed :)

[danilvalov]

+1

[serebro]

+1

[antony]

Also experiencing this problem. We have QA environments that might need the database to be rolled backwards and forwards depending on what is deployed there at any given time.

I think that both the CLI and the programmatic methods should allow a forced 'down', which doesn't concern itself with what ran previously, etc.

[emirotin]

I agree it makes total sense.
If I build it will you have chance to properly test it in real use-cases?

On Thu, Jul 7, 2016 at 2:11 PM Antony Jones notifications@github.com
wrote:

Also experiencing this problem. We have QA environments that might need
the database to be rolled backwards and forwards depending on what is
deployed there at any given time.

I think that both the CLI and the programmatic methods should allow a
forced 'down', which doesn't concern itself with what ran previously, etc.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#8 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAgGCAWfI23ySk_Kcwok1MWwZDRRABGQks5qTN79gaJpZM4D2em8
.

[antony]

Yeah, absolutely!

On Thu, 7 Jul 2016, 12:20 Eugene Mirotin, notifications@github.com wrote:

I agree it makes total sense.
If I build it will you have chance to properly test it in real use-cases?

On Thu, Jul 7, 2016 at 2:11 PM Antony Jones notifications@github.com
wrote:

Also experiencing this problem. We have QA environments that might need
the database to be rolled backwards and forwards depending on what is
deployed there at any given time.

I think that both the CLI and the programmatic methods should allow a
forced 'down', which doesn't concern itself with what ran previously,
etc.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
#8 (comment)
,
or mute the thread
<
https://github.com/notifications/unsubscribe/AAgGCAWfI23ySk_Kcwok1MWwZDRRABGQks5qTN79gaJpZM4D2em8

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#8 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AANXRXKf6I-pYhNurMsUNe0WBugmPz3lks5qTOECgaJpZM4D2em8
.

[emirotin]

Thanks, I'll try to make some time for that, maybe early next week.

On Thu, Jul 7, 2016 at 3:28 PM Antony Jones notifications@github.com
wrote:

Yeah, absolutely!

On Thu, 7 Jul 2016, 12:20 Eugene Mirotin, notifications@github.com
wrote:

I agree it makes total sense.
If I build it will you have chance to properly test it in real use-cases?

On Thu, Jul 7, 2016 at 2:11 PM Antony Jones notifications@github.com
wrote:

Also experiencing this problem. We have QA environments that might need
the database to be rolled backwards and forwards depending on what is
deployed there at any given time.

I think that both the CLI and the programmatic methods should allow a
forced 'down', which doesn't concern itself with what ran previously,
etc.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<

#8 (comment)

,
or mute the thread
<

https://github.com/notifications/unsubscribe/AAgGCAWfI23ySk_Kcwok1MWwZDRRABGQks5qTN79gaJpZM4D2em8

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
#8 (comment)
,
or mute the thread
<
https://github.com/notifications/unsubscribe/AANXRXKf6I-pYhNurMsUNe0WBugmPz3lks5qTOECgaJpZM4D2em8

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#8 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAgGCDcxdB34DdqhvREIeVvmsAJzM7Q2ks5qTPDQgaJpZM4D2em8
.

[patkruk]

Hey. Any update on this? Thx.

[antony]

Hey @emirotin @patkruk sorry we've not done any DB migrations since, so I don't have a 'real' use case at the moment.

I'm fairly sure we will have a few migrations to be done by January.

[emirotin]

@antony FYI I'm working on it right now and plan to publish the new experimental version early this week (CC @patkruk)

[antony]

Hey @emirotin ok - excellent. Sadly one of my developers took it upon themselves to migrate our project away from this module, so I won't have a real use case any more.

Nevertheless, ping me if you need some help testing and I'll be happy to do so.

[emirotin]

Well, that's understandable, I didn't pay attention to a couple of issue for quite some time.

[emirotin]

Anybody interested can try the run-custom-sets branch and report any problems with it.
I'm still working on testing and documenting it.

[davidgustys]

Hey @emirotin have you made any progress on this issue?

[emirotin]

The feature is implemented in a branch (see the previous comment in this thread), so you can use it by switching your npm dependency to emirotin/mongodb-migrations#run-custom-sets

The automated tests for it are not yet done — busy doing other things currently.

[balkarov]

I use this
mongodb-migrations.git#run-custom-sets

And my code:

migrator.rollback(function (error, results) {
    if (error)
        console.error(error);
    migrator.dispose(function () {
        console.log("DISCONNECTED!");
    });
    console.log(results);
});

But I get error

Error: Rollback can only be ran after migrate

How use rollback?

[emirotin]

Rollback is still not intended to be used this way.
The meaning of rollback is as in SQL: you try someting (migrate), if it fails you roll it back by automatically undoing all the actions in the reverse order.

It looks like I forgot to expose the two new methods to the public API (they're implemented in the runner but not made available through the public migrator interface).
My bad.
Will fix and let you know here.

[emirotin]

@balkarov can you try now using a method called migrator .runDown?
The rest should supposedly stay the same.

[dwhelan]

Hey @emirotin I am interested in this capability so I was checking it out. I found a couple of things that I hope might be useful feedback.

Using a single migration:

# 1-test.js

'use strict';

module.exports.id = "test";

module.exports.up = function (done) {
  this.log("up 1");
  done();
};

module.exports.down = function (done) {
  this.log("down 1");
  done();
};

When I run mm down the migration works but I do not get any console or log output like I do with mm migrate.

$ ./node_modules/.bin/mm migrate
   up 1
     Migration 'test': ok
$ ./node_modules/.bin/mm down
$ ./node_modules/.bin/mm migrate
   up 1
     Migration 'test': ok

Clearly mm down worked but the log in the down function did not do anything. Also, it would be useful if the there was a console output like `Migration 'test' rolled back'.

Similar results for mm up:

$ ./node_modules/.bin/mm up
$ ./node_modules/.bin/mm migrate
     Migration 'test': skip (migration already ran)

[deanshub]

@emirotin ./node_modules/.bin/mm down works like a charm for me,
when are you going to merge the run-custom-sets branch and publish a new version to npm?

[builtinnya]

For those who are struggling with rollback of specific migrations from CLI, which is not working as intended, I submitted a pull request (#51) to fix the bug.