urbica/pg-migrate

PostgreSQL migration tool

Urbica PG Migrate

PostgreSQL migration tool.

Documentation.

Installation

pg-migrate requires node v7.6.0 or higher for ES2015 and async function support.

npm install -g @urbica/pg-migrate

...or build from source

git clone https://github.com/urbica/pg-migrate.git
cd pg-migrate
npm install

Usage

Usage:
  pg-migrate [options] new <name>
  pg-migrate [options] migrate
  pg-migrate [options] rollback <N>
  pg-migrate [options] reset
  pg-migrate --help
  pg-migrate --version

Examples:
  pg-migrate new create-users
  pg-migrate migrate
  pg-migrate rollback 1
  pg-migrate reset

Options:
  --help                        Show this screen
  --version                     Show version
  --verbose                     Show verbose output
  -m --migrations-dir=DIR       The directory containing your migration files [default: ./migrations]
  -t --migrations-table=TABLE   Set the name of the migrations table          [default: migrations]
  -s --migrations-schema=SCHEMA Set the name of the migrations table scheme   [default: public]

Connection options:
  -c --connection=DATABASE_URL        database connection string in libpq format
  -d --db=PGDATABASE                  database name to connect to
  -h --host=PGHOST                    database server host or socket directory      [default: localhost]
  -p --port=PGPORT                    database server port                          [default: 5432]
  -U --user=PGUSER                    database user name
  -W --password=PGPASSWORD            database user name password

Node.js API

Using Promises

const PgMigrate = require('@urbica/pg-migrate');
const pgMigrate = new PgMigrate({
  database: 'test',
  migrationsDir: './migrations'
});

pgMigrate
  .connect()
  .then(() => pgMigrate.migrate())
  .then(() => pgMigrate.end());

...or using async/await

const pgMigrate = new PgMigrate({ database, user, migrationsDir });

async function migrate() {
  await pgMigrate.connect();
  await pgMigrate.migrate();
  await pgMigrate.end();
}

migrate();

See API for more info.

pg-migrate's Issues

SSL defaults to "false", which is not a valid value.

Hello,

I think that because the -ssl option is not a flag but an option, docopt generates the string value 'false' when it's not present.
This is not a legal value for that option (need conversion to a boolean). Furthermore, because the string 'false' is truthy,
we can't provide the option via environment variables.

...
// Environment variables never get used because opt is the string "false" 
ssl: opt['--ssl'] || process.env.PGSSL || process.env.POSTGRES_SSL
...

Thanks for the otherwise nice library.

Fails to create migration table if schema doesn't exist.

When I use --migrations-schema to set the schema, it fails become the schema doesn't exist yet. It would be helpful if this utility would create the schema if it doesn't exist.

Ability to read existing schema and lock it ( including PostGIS)

Hello! Thanks for a great tool!

Wondering if there is any planned support for ability read existing schema and lock in the schema for future migrations? Especially interested in PostGIS datatypes.

Here's a similar project that reads existing schema, but it doesn't yet support postgis:

https://github.com/ariga/atlas

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml
• The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

• engines was only updated if it defined a single version, not a range.
• .nvmrc was updated to Node.js 10
• .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴