Feature request: Timestamps instead of incrementing ids about automigrate HOT 2 OPEN

The downside is that before merging a PR, we have to ensure that there is no clash in migration numbers.

For our use-case, this would be a massive issue. We merge changesets to main 10+ times a day, and any number of them will have migrations. If we had to rebase/update every time someone merged, we'd be significantly slowed down.

I don't see us switching either way, we're tied to migratus, so don't rush to make any changes for us. I just want to make you aware of the trade offs here.

from automigrate.

@NoahTheDuke Hi! Thank you for the feedback and for creating the first issue!

I considered using timestamps instead of incremented integers as the number of a migration version when I was building this part of the library, but decided to go with integer numbers. The reason involves a couple of considerations:

• from my point of view, the application order of migrations should be predictable and explicit;
  • with timestamps, there's a possible scenario where a merged and already applied migration in the main branch has a more recent timestamp than the migration from a PR; in this case, the migration with the older timestamp would be applied in the wrong order according to the timestamps;
• this approach (with an unfixed order of migration application) works well if migrations don't depend on each other, for example, for different tables; but sometimes if migrations relate to the same table or same columns, they must be applied in a particular order; the approach with incremented integer numbers guarantees this, whereas with timestamps you have to track it on your own;
• the integer number of a migration is useful for the explain command and for migrating in forward or backward directions to a particular migration.

The downside is that before merging a PR, we have to ensure that there is no clash in migration numbers. The good part is that Automigrate has validation for this and will notify about duplicated migration numbers.

I think, we can keep this issue for a while in case there are other solutions on this to consider or discuss.

from automigrate.