Feature request: Timestamps instead of incrementing ids

[NoahTheDuke]

This library looks super cool, thanks for building it.

I work in a large engineering org with multiple teams. We use migratus which uses timestamps as the migration "number". This means that no matter how many people generate migrations on separate branches, there's no conflicts when they're merged to main.

Is there planned support for using timestamps (ISO 8601) as the number instead of a padded integer?

[abogoyavlensky]

@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.

[NoahTheDuke]

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.