Description
What is your suggestion?
Instead of using migration IDs like 1_add_table we should use timestamp-based IDs like 1654116390_add_table.
Why do you want this feature?
Using sequential IDs and enforcing uniqueness is difficult to do. We have a test to enforce uniqueness, but if you have two PRs at the same time that use the same migration ID, the tests will pass as the migrations are only checked for uniqueness against main and not each other. So theoretically you could merge two PRs with the same migration ID and cause fatal errors in prod.
See #1968 for an example where this happened and got past the linter.
Switching to Unix timestamp-based IDs avoids this problem as it will only happen if the two devs made the two different migrations at the exact same second, which given how many migrations we have right now, seems very unlikely. The same test we have for uniqueness can still be employed as well even though it's imperfect.
In Coder v1 we use timestamp migration numbers.
Alternatively we could use YYYY_MM_DD__HH_mm_add_table but that may be more work to support for little gain
Are there any workarounds to get this functionality today?
n/a
Are you interested in submitting a PR for this?
Maybe, but I think it would be better if someone more familiar with the migration code handled this