fullcube / loopback-component-migrate Goto Github PK

It would be really nice to be able to run migrations that apply to the current environment. The implementation could be similar to how Loopback currently deals with environment based configs. For example, if you only want to run a migration on stage you could name you file 0001-migration.stage.js or if you only wanted to run it on production, it would be 0001-migration.production.js.

Version 3.19.1 of loopback was just published.

This version is covered by your current version range and after updating it in your project the build failed.

loopback is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Version 2.0.4 of ghooks was just published.

This version is covered by your current version range and after updating it in your project the build failed.

ghooks is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Is there any way to generate migration file?

I'm implementing the migration in a boot script before my actual application code is run like this:

const loopback = require('loopback');
const Migration = loopback.getModel('Migration');

module.exports = app => {
  Migration.migrate('up', error => {
    if (error) {
      console.error('Error in migrations: %s', error.stack);
      return;
    }

    console.log('boot app now');
  });
};

This works when there are actual migrations pending. However, if not, I see "No new migrations to run." outputted, but the "boot app now" log line never gets executed.

If I put cb() here: https://github.com/fullcube/loopback-component-migrate/blob/master/lib/models/migration.js#L152, it works ok, but I'm pretty sure that's not correct, also, this wouldn't return a promise. I'm not sure how to fix this in the right way.

Currently, migrationsDir expects an absolute path (even though the default value of server/migrations is relative). Path should be relative to the application root.

Version 2.16.0 of commander was just published.

This version is covered by your current version range and after updating it in your project the build failed.

commander is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

I think you should be able to select the data source that you're migrating as part of the API rather than only selecting a single data source in a config file.

While working on the pull request I just submitted, I noticed that the MigrationMap model seems unused. Apart from the index.js defining the model and the files that define the model, there is absolutely no reference to it.

Can it be removed? I'd rather not have unused tables in my database... :)

Cheers,

Jouke

No where in the docs its mentioned how to generate migration files

The vulnerability report shows that there is a dependency with security issues.
https://david-dm.org/fullcube/loopback-component-migrate

The recommended path is to update the package
https://nodesecurity.io/advisories/534

Version 3.5.2 of bluebird was just published.

This version is covered by your current version range and after updating it in your project the build failed.

bluebird is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

It looks like this components is currently only working properly when using the in memory datasource.

I have tried changing the datasource to MySQL and i'm getting errors because the table doesnt exist.

How can I run migrations from a command like npm run migrate?

also where to put Migrate.migrate('up', function(err) {});??

I thought I should be implementing this using the CLI so that it could be part of a deploy sequence, something like:

Note: I've aliased loopback-component-migrate binary command to lcm

1. npm install
2. lcm up
3. node server.js

I created a migration via lcm create initial which created the migration file in ./migrations/20160810101725-initial.js. The migration file looks like:

module.exports = {
  up: function(dataSource, next) {
    console.log('running initial up');
    next();
  },
  down: function(dataSource, next) {
    console.log('running initial down');
    next();
  }
};

When I run lcm up, first thing output is "Migrating up to: "20160810101725-initial.js" [TODO]" and then I see output from starting the app up, just like I'd see if I ran node server.js. I don't see the logs I inserted into the migration or anything. The app continues to listen for web requests/socket messages...

I'm using MongoDB as my data store and when I look inside, I don't see a collection for Migrations or anything.