add support for running all migration files regardless of timestamp

[lirantal]

Addresses #20
The addition of the extra i or --ignore-timestamp flag isn't breaking any functionality and enables running all migrations, regardless of timestamp.

[coveralls]

Coverage decreased (-1.0%) to 97.25% when pulling ad784eb on lirantal:feat/run-all-migrations into ac92478 on vinicius0026:master.

[vinicius0026]

I'm not sure if this PR would satisfy the request on #20. As fas as I understood it, the request was to run a single migration by name (which could be done by matching filenames in migration directory).

[lirantal]

@vinicius0026 you're right, I was confused by that issue since you referred to it in another issue and searching the issue queue now, I see that I never actually reported this problem (though I remember I did), but basically the issue is that you should be able to support just running migration files regardless of time the last migration was inserted into the database.

Use case:

1. I have directory init which has some migrations to create databases, tables, etc
2. I have another directory which is called migrations to run migrations

In timeline perspective this happens:

1. I create an init migration file
2. I create a migrations migration file

Then I run both of them and insert into the database.
In the meanwhile, another colleague in another branch create an init migration file as well at the same time, or even before me.

Problem: when he merges the code and execute migrations his init migration will fail because the latest migration that was ran is the file in migrations directory.

That's one use case but there are other reasons for why you wouldn't want to impose the rule of only inserting migrations that are newer than the timestamp on the db.

[vinicius0026]

@lirantal Now I understand your point, but I'm not sure this is the best way to go.

In the described use case, suppose your work and the work from your colleague are merged. Then you both would have to update your local repositories and run migrations again. This would cause your migrations to be run twice in your machine, and his migrations would run twice on his, which could yield errors and would require guards against them in migrations code.

I think a better way to deal with the situation you describe is replacing the logic that filters migrations by their timestamp by some that checks in the migrations metadata table which migrations were run and which were not, and then run only the un-run migrations.

What are your thoughts?

[lirantal]

If you mean that we would run migrations again because we'll need to update our codebase and run new migrations, then how would we run the same migration twice?
The code change is about ignoring the time diff that you're checking, but it's not going to run the same migration file twice. Take a look again at the code because to begin with, in that promise chain there is already a check that builds an array of migration files that haven't been executed yet.

Also, the notion of coupling migrations with the date they executed is something that I see for the first time. Sequelize and other libraries of other languages don't have this (http://docs.sequelizejs.com/manual/tutorial/migrations.html).

What I like about the approach in this PR is that rethinkdb-migrate stays as is and doesn't break for anyone who wishes to keep using the same functionality, but rather they can opt-in for the newly proposed migrations execution method.

[vinicius0026]

@lirantal You're right! Its been a while since I last read this code.

Merging this right now. And I think we should drop filterMigrationsOlderThan all together, when moving to v2, don't you think?

[lirantal]

Thanks.
@vinicius0026 I'm not sure who uses it or actually relies on it which is why I didn't want to break that functionality. If you think it's worth keeping then maybe in v2 we can switch the defaults so if you want to enable filtering based on date you need to provide a flag.

[vinicius0026]

@lirantal I'm not sure if anyone relies on this at all. It was a bad design decision on my side, never had second thoughts about it until now.
Anyway, switching the defaults seems like a good way to go.