Add ability to use IDENTITY instead of SERIAL on Redshift

[wzrdtales]

Create a new driver from the postgresql driver with minor changes to provide a better Redshift support.

We need to use IDENTITY instead of SERIAL, amazon doesn't use the same datatype for autoIncrements like it is done in postgresql.

Also refers and fixes parts #288

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[jrdi]

I am going to work on this issue but I don't know how to implement it. Can I create the new driver inside this repo and you will move it to a separate repo like pg, mysql, etc?

BTW, why do you need an id in this table? name and run_on should be enough for a migrations table...

[wzrdtales]

No, every table should always have an id. You need it to reference it, delete entries with it and so on. Only the pk is a trustable unique identifier with reasonable performance while searching through the table.

If you want to work on this, you may start in your own repo for a driver and start working on it in the new driver model. We can transfer this repo into the db-migrate organization later too if you want it to be officially supported. I also could create the project and invite you into the team of the organization. Just let me know what you do prefer.

[wzrdtales]

@jrdi And one example is already given, 0.10.x already introduces a relationship from the migration table to another one. The seeder and migrations are related to each other. And as you can use seeders and migrations independently, Seeders are not just a part of the migration.

Also to note, using an auto incremented PK is a best practice. Like in this example we're going to extend the functionality at some time and might want to reference it.

[jrdi]

@wzrdtales Where did you use this id? You always use name to delete entries, so don't have much sense to maintain a non used field. If you want a pk you can use name as it.

I tried to run from master using modules for each driver and I can't make it run, maybe I am missing something but I didn't see what to proceed on the readme.

[wzrdtales]

The documentation for the new driver model is not completed yet. A bit is yet described here:

http://db-migrate.readthedocs.org/en/latest/Developers/contributing/#creating-your-own-driver

You would start by creating your package json, name your package in the following schema db-migrate-drivername and install the db-migrate-pg dependency. In this case you don't need the base dependency as you're going to extend (and overwrite some functions) the pg driver.
To make db-migrate include your driver you specify it by its drivername, db-migrate searchs for the driver in your node_modules first, if it doesn't find it there, it looks if there is a folder with the name of your module one level up from the db-migrate root (this is used if you install db-migrate globally).

So there are some optionalities, the first is to install the developer version (master branch) of db-migrate globally. You do this best by just using npm link and next do the same with your driver you're going to develop. This way db-migrate should be able to find it. Another way is to just link your new driver and define the NODE_PATH. This way you can use db-migrate without installing it globally.

Alternatively you can first create the driver within the /lib/drivers/ directory and name it just with your drivername and move it later to its own repository.

[wzrdtales]

@jrdi Considering your question of the PK, read my last note. I will try to help you getting started, I'm away for some hours now, but just leave questions here and I will answer them.

[wzrdtales]

@jrdi I just noticed you have started working on the v0.9.x track, you need to start on the v0.10.x track (current master) instead.

[jrdi]

@wzrdtales I know, but I need a fast fix in order to use db-migrate with redshift. Now I'm using this quick fix but I will try to implement it to v0.10.x later.