Migration Name Ignored

[benbotto]

I would like to bring down a single migration by name, but when I try to run a down migration by name the name appears to be ignored.

$ db-migrate down "/20161010235332-change-userID-to-unsigned" --migrations-dir ./api/db/migration --config ./api/db/migration/database.json --verbose
[INFO] Detected and using the projects local version of db-migrate. '/home/avejidah/programming/cea-exam/node_modules/db-migrate/index.js'
[INFO] Using dev settings: { driver: 'mysql',
  user: '[REDACTED],
  password: '******',
  database: [REDACTED],
  multipleStatements: true }
[INFO] require: db-migrate-mysql
[INFO] connecting
[INFO] connected
[INFO] creating table: migrations
[SQL] CREATE TABLE IF NOT EXISTS `migrations` (`id` INTEGER  PRIMARY KEY AUTO_INCREMENT NOT NULL, `name` VARCHAR (255) NOT NULL, `run_on` DATETIME  NOT NULL)
[INFO] loading migrations from database
[SQL] SELECT * FROM `migrations` ORDER BY run_on DESC, name DESC
[INFO] preparing to run down migration: 20161015004119-update-numberOfQuestions-in-objectives
[SQL] SET AUTOCOMMIT=0;
[SQL] START TRANSACTION;
[ERROR] Error: Cannot find module '/home/avejidah/programming/cea-exam/api/db/migration/20161015004119-update-numberOfQuestions-in-objectives'
    at Function.Module._resolveFilename (module.js:455:15)
    at Function.Module._load (module.js:403:25)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)
    at Class.setup (/home/avejidah/programming/cea-exam/node_modules/db-migrate/lib/skeleton.js:157:12)
    at /home/avejidah/programming/cea-exam/node_modules/db-migrate/lib/migrator.js:220:33
    at tryCatcher (/home/avejidah/programming/cea-exam/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/home/avejidah/programming/cea-exam/node_modules/bluebird/js/release/promise.js:510:31)
    at Promise._settlePromise (/home/avejidah/programming/cea-exam/node_modules/bluebird/js/release/promise.js:567:18)
    at Promise._settlePromise0 (/home/avejidah/programming/cea-exam/node_modules/bluebird/js/release/promise.js:612:10)
    at Promise._settlePromises (/home/avejidah/programming/cea-exam/node_modules/bluebird/js/release/promise.js:691:18)
    at Async._drainQueue (/home/avejidah/programming/cea-exam/node_modules/bluebird/js/release/async.js:138:16)
    at Async._drainQueues (/home/avejidah/programming/cea-exam/node_modules/bluebird/js/release/async.js:148:10)
    at Immediate.Async.drainQueues (/home/avejidah/programming/cea-exam/node_modules/bluebird/js/release/async.js:17:14)
    at runCallback (timers.js:574:20)
    at tryOnImmediate (timers.js:554:5)

Node version 6.6.0
npm version 3.10.8
db-migrate-0.10.0-beta.20
db-migrate-mysql-1.1.9

Thank you!

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[wzrdtales]

@benbotto This is and won't be possible.

If you specify a name for a down migration, it will migrate down all migrations until it reaches the one you declared.

But your posted verbose run indicates also something different. It seems that you deleted the migration 20161015004119-update-numberOfQuestions-in-objectives before reversing the migration itself. If you do this, this runs into the error thrown in your verbose run. You need to clean up this row in the migrations by yourself now or restore the migration with that name.

Another thing is that you confuse something. If you enter a target to migrate down to, you define the destination, that means, the migration name (the date already is enough btw.) is not being down migrated as it is the destination. It is the same for up, but in the case of up the destination is being executed as this is how it is expected to work.
The expectation can be defined as of the following:
A specification of migration is expected to bring the database in the state of the specified migration.

Therefore a down migration must not execute the down routine of the destination, as this wouldn't equal the state specified anymore and an up migration must execute the up routine of the destination as otherwise it also wouldn't equal the state specified anymore.

So if you want to run down to a migration including the migration you want to have run down, you would need to specify the migration before the one you target. But I guess it would make sense to add a command line option to add some more comfort here :) (or maybe add this to the reset command which would match that behavior you describe from its definition)

In your case please also check your migrations folder and table as there is something wrong as stated from the error thrown in your example.

[benbotto]

Ah, I see. Thanks. I missed this line in the documentation: "migrationName is ignored for down migrations." I read the part specific to using a date in an up, and then the part that states "All of the down migrations work identically to the up migrations by substituting the word down for up." I incorrectly assumed that down could be used for a single migration, but what you've said above clears it up.

Regarding the missing migration, it's just in a feature branch. The verbose output above came from a branch that does not yet have the 20161015004119-update-numberOfQuestions-in-objectives migration.

Thanks again.