Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate down from CLI #8

Open
slonoed opened this issue Mar 28, 2015 · 30 comments
Open

Migrate down from CLI #8

slonoed opened this issue Mar 28, 2015 · 30 comments

Comments

@slonoed
Copy link

slonoed commented Mar 28, 2015

Can I do it?

@emirotin
Copy link
Owner

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
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link
Owner

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

@tjaartvdwalt
Copy link

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
Copy link
Owner

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
Copy link

kryz81 commented May 13, 2016

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

@danilvalov
Copy link

+1

1 similar comment
@serebro
Copy link

serebro commented Jun 18, 2016

+1

@antony
Copy link

antony commented Jul 7, 2016

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
Copy link
Owner

emirotin commented Jul 7, 2016

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
Copy link

antony commented Jul 7, 2016

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
Copy link
Owner

emirotin commented Jul 7, 2016

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
Copy link
Contributor

patkruk commented Nov 1, 2016

Hey. Any update on this? Thx.

@antony
Copy link

antony commented Nov 2, 2016

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
Copy link
Owner

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

@antony
Copy link

antony commented Dec 11, 2016

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
Copy link
Owner

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

@emirotin
Copy link
Owner

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
Copy link

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

@emirotin
Copy link
Owner

emirotin commented Feb 8, 2017

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
Copy link

balkarov commented Feb 22, 2017

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
Copy link
Owner

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
Copy link
Owner

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

@dwhelan
Copy link

dwhelan commented Mar 3, 2017

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
Copy link

@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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests