Config file and type shorthands

[dolezel]

Fixes #87

[roman-kaspar]

small details to fix in the comments.
otherwise LGTM.

[roman-kaspar]

config configuration file?
---> I would omit the middle "configuration" word here.

[roman-kaspar]

why is user and password in square brackets here?

should it read:
either url, or [user, password, host (...), port, name] - for connection details
?

[dolezel]

It means that user and password are optional (you can have user without password and if you do not specify user, logged in user is used)

[roman-kaspar]

aha, OK :-)

[roman-kaspar]

the bracket before "e.g." is not closed here.

[mzuniga84]

Can someone provide a real example of how to use this feature? I have been trying in different ways without any success.

Thank you

[roman-kaspar]

here I would say "it will in ..." instead of just "will in".

[dolezel]

@mzuniga84
This is a working custom config file configuration with type shorthands:

const PgLiteral = require('node-pg-migrate').PgLiteral;
module.exports = {
  "type-shorthands": {
    id: {
      type: 'uuid',
      primaryKey: true
    },
    createdAt: {
      type: 'timestamp',
      notNull: true,
      default: new PgLiteral('current_timestamp')
    }
  }
};

Run it as pg-migrate -f ./config.js

[flux627]

Would there be any way to "version" this shorthand file in tandem with migrations? As in, I want to record in my migrations when these shorthands change, as changing this file necessarily breaks all migrations dependent on it.

[dolezel]

That's true :(
Thinking about it, I think that it can be version in a way, that if type-shorthands contains numeric index it is treated as timestamp and for migrations before this timestamp this configuration is taken.
E.g.

const PgLiteral = require('node-pg-migrate').PgLiteral;
module.exports = {
  "type-shorthands": {
    1517827323: {
      id: {
        type: 'uuid',
        primaryKey: true
      },
      createdAt: {
        type: 'timestamp',
        notNull: true,
      }
    },
    id: {
      type: 'uuid',
      primaryKey: true
    },
    createdAt: {
      type: 'timestamp',
      notNull: true,
      default: new PgLiteral('current_timestamp')
    }
  }
};

What do you think @flux627 ?

[flux627]

I would prefer a multi-file solution to both match the migrations pattern and keep things clear.

Maybe if you specify a directory instead of a file, it can parse a timestamp at the beginning of the string and use the most recent definitions for a given migration timestamp.

At that point though, I think it would make much more sense to define these shorthands within the migration files themselves. Something like:

exports.shorthands = {
  // Shorthands go here
}

exports.up = function up(pgm) {
  ...
}
exports.down = function down(pgm) {
  ...
}

It then would share these definitions for subsequent migrations, unless they are updated. If this was implemented I would be a very happy camper :)

[flux627]

With this, if you wanted to, you could even have migrations files dedicated to shorthand updates, which would arguably be much cleaner.