Given the following migrations:
- 20100101101011_Do_something
- 20100101101012_Do_something_Else
- 20100101101013_Do_something_another
- 20100101101014_Do_something_yet_another
- 20100101101015_Do_something_once_more
Say we apply the first two when we go live in release 1. Now our
prod database has:
- 20100101101011_Do_something
- 20100101101012_Do_something_Else
Applied in this order. Now in release 2 we apply the last
two:
- 20100101101014_Do_something_yet_another
- 20100101101015_Do_something_once_more
The middle one (20100101101013_Do_something_another) is in a
branch not ready for production.
Then after some time we apply the last one. Now our database has
the following versions applied (in this order):
- 20100101101011_Do_something
- 20100101101012_Do_something_Else
- 20100101101014_Do_something_yet_another
- 20100101101015_Do_something_once_more
- 20100101101013_Do_something_another
This is fine, since it was the actual order we applied them. The
issue is if we try to go down to
20100101101015_Do_something_once_more. We'll get an error because
db-migrate tries to order the migrations based in timestamp (which
clearly does not work in this context).
There should be an abstract id that gets auto-incremented for
every migration. The rollback should be executed based in this
id.
Wandenberg Peixoto