building5 / sails-db-migrate Goto Github PK

I'm having trouble figuring out if there's a way to support SSL connections using this package.

node-db-migrate seems to support it...sort of.
db-migrate/node-db-migrate#79

However, the only way they support it is by adding a config option to the database.son file, native: true. I don't fully understand how this works, but I think it's forcing the pg package to use the native version of postgres or something along those lines.

In any case, the way sails-db-migrate works, it just sets process.env.DATABASE_URL. When control is passed over to node-db-migrate, it sees that process.env.DATABASE_URL is set, and loads the configuration for the connection from this string alone. It doesn't look to any other config settings as far as I can tell.

So I don't see anyway to use SSL with sails-db-migrate, and I'm also not sure there's a way to support it with the current way node-db-migrate operates.

Am I missing something? Any ideas on fixes?

For exmaple,

[WARN] Using unknown data type VARCHAR
[INFO] Done

Done, without errors.

Its normal ? Warring or Error.

ps. may be its question to "node-db-migrate"

sails.lift dont wont to start with port "-1"

Fatal error: "port" argument must be >= 0 and < 65536

Can you change it with sails.load, so it is dont run http server?

The README says this module supports version 0.10. Any plans to support 0.11? Any known issues with attempting to use this with 0.11?

Thanks!

your peerDependencies screws up the latest version of sails that's about to be released. also, npm is phasing out that feature anyway.

grunt process often remains after this.

grunt db:migrate:create --name add-some-fooz

I have an application where the bootstrap performs some initialization where it reads from the models and sets up some state to be used by the application. If this operation fails to complete, bootstrap doesn't succeed and sails never finishes lifting.

I have a catch-22 here, because I want to be able to have an initial migration for the database used by the bootstrap initialization, but the bootstrap must complete for sails-db-migrate to run the migration.

I'm thinking that in order to address this, we need some way to read the sails configuration without lifting sails... :(

HI guys, first of all a big cheers for this package that makes migrations a lot easier!

Is there a way to specify that connections are defined in a file other then 'connections.js'?
I define them in /env/production.js and /env/development.js.
Haven't found any related questions on SO or in the documentation.

Thanks!

Running "db:migrate:create" (db:migrate) task
+ db-migrate create addSubscriberTable
Fatal error: could not find connection ProdPostgresql in ./config/connections.js

It would be great if one could set the environment in which to run the migrations.
For example in rails, one has to do:
rake db:migrate RAILS_ENV=testing

so it would be cool to add this to sails-db-migrate.

grunt db:migrate SAILS_ENV=testing

What do you think?

This package is looking for connector from config/connections.js file but could not find anything because in new version config/connections.js is replaced with config/datastores.js. Any one can help?

Running migration

$ grunt db:migrate:up --dry-run
Running "db:migrate:up" (db:migrate) task
db-migrate up --dry-run
DATABASE_URL=mysql://root:****@localhost:3306/db_name
Fatal error: spawn Unknown system errno 193

I know your README reports that this supports Sails 0.10.x, but I've isolated a warning to this package (I think), so I figured I would report it for your consideration.

grunt db:migrate:up reports a warning about promises...

Running "db:migrate:up" (db:migrate) task
+ db-migrate up
DATABASE_URL=postgres://localhost/sailsdbtest
[INFO] Processed migration 20160410210432-add-pets
Warning: a promise was created in a handler but was not returned from it
    at Object.Base.extend.close (/Users/sarahallen/src/18F/sailsdbtest/node_modules/db-migrate-pg/index.js:477:26)
    at onComplete (/Users/sarahallen/src/18F/sailsdbtest/node_modules/db-migrate/api.js:857:19)
    at /Users/sarahallen/src/18F/sailsdbtest/node_modules/db-migrate/lib/migrator.js:172:11
From previous event:
    at /Users/sarahallen/src/18F/sailsdbtest/node_modules/db-migrate/lib/migrator.js:171:10
    at /Users/sarahallen/src/18F/sailsdbtest/node_modules/db-migrate/lib/migration.js:339:7
    at processImmediate [as _immediateCallback] (timers.js:383:17)

[INFO] Done

I've reproduced this in a very tiny Sails app and verified that if I use plain old db-migrate up from the node module (without sails-db-migrate) that I don't get the warning

Isolated Test Case

You can clone the simple app here -- The master branch just has the warning, the no-warn branch includes a database.json required to run the vanilla db-migrate

Steps:

nvm use 4.2.2
sails --version
0.12.3

sails new sailsdbtest
cd sailsdbtest
npm install sails-postgresql --save
npm install db-migrate --save-dev
npm install db-migrate-pg --save-dev
npm install sails-db-migrate --save-dev

echo "module.exports = require('sails-db-migrate').gruntTasks;" >> tasks/register/dbMigrate.js

createdb sailsdbtest

in config/migrations.js:

module.exports.migrations = {
  connection: 'postgresql'
};

grunt db:migrate:create --name add-pets
grunt db:migrate:up

db-migrate is currently at version 0.9.2, sails is now at 0.11.0.
The peer dependencies for sails-db-migrate prevent both of these modules from being updated.

There doesn't appear to be anything compelling that prevents the peer dependencies to be updated, that I can tell so far in testing.

I am running sails-db-migrate on my sails app, and when i load the app in debug mode in Webstorm 9.0 Build WS-139.164, as soon as the debugger goes into the sails db migrate code, it never comes back out and the application seemingly just hangs.

I have noticed that sails-db-migrate uses child-process.fork to run db-migrate. In Webstorm, this is the console output that I get when I load my app:

debugger listening on port 52600
debugger listening on port 52600

So seemingly, the db-migrate process is loading up listening on the same debugger port, which could definitely be causing the problem. Going to look into it.

Every command i run results in an error:

grunt db:migrate:create --name add-some-fooz --force

Error:

Warning: Task "add-some-fooz" not found. Used --force, continuing.

Running "db:migrate:create" (db:migrate) task
Fatal error: Could not load sails

In addition to updating the table schema, you need to fill them with data. For this there must be a separate grunt task. In the task, you can specify the source file that will contain code to generate the data (by use modules which the developer wants)

Is there a way to use it with mongodb?

I got this error :

Fatal error: migrations not supported for sails-mongo

Hi,

I want to use SQL for migration.
My migration script contains multiple queries, but sails-db-migrate does not path multipleStatements to DATABASE_URL.

Can you fix the issue or is there anyway to execute multiple queries?

In my connections.js, I have a following setting.

multipleStatements: true

but in the init process, it ignores the setting above.

I think lib/sailsDbMigrate.js does not take the setting.

Thanks.

I'm running into an interesting situation. I'm trying to seed data into the database in the config/bootstrap.js file. This was recommended by a number of folks as the best way to handle seed data.

When running grunt db:migrate:up, sails-db-migrate lifts the sails server, which calls the bootstrap.js file, which starts trying to seed my data into the database that hasn't had the migrations run on it yet.

I'm wondering what you think a good solution for this might be. I've thought of a couple things.

1. Just do my seed in a migration file. This works Ok, but isn't great since you can't see all your seed data in one place.
2. Add a runtime variable when lifting sails in sails-db-migrate that I can key off in the bootstrap.js file. For example: Sails.lift({ port: -1, log: {level: 'silent'}, environment: env, migrating: true}, .... This way in bootstrap.js I can choose not to insert my seed data if the server is just getting lifted for migrations.

I'm open to other ideas as well, and definitely willing to help with a pull request. Let me know what you think might work best.

Yeah, common mistake :)