fullcube / loopback-component-migrate

Migration framework for loopback
43 stars 30 forks source link

Question: How do you implement this via CLI? #5

Open sundeepgupta opened 8 years ago

sundeepgupta commented 8 years ago

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.

jcolemorrison commented 7 years ago

when I use the CLI up command it just hangs for me on the Migrating up to: "name-of-migrationfile" [TODO]

jcolemorrison commented 7 years ago

For anyone else having troubles with this, I just gave up. This doesn't seem to work at all with 3.x. There's actually a pretty reliable pattern you can achieve just using automigrate when you need to create new tables or seed data and then autoupdate to keep things in sync without having to worry about a convoluted solution:

Authorized Resources and Database Migrations with Strongloop's Loopback

curioustushar commented 7 years ago

any plans to implement these features?

@sundeepgupta any idea?

mrfelton commented 6 years ago

Thanks for implementing this @ivesdebruycker

mrfelton commented 6 years ago

@jcolemorrison this package is less about keeping database schema changes in sync (which you can do with autoupdate as you mention), and more about running data migrations against your database in order to change your existing data if your application's data expectations change.