Another approach to conflicting migrations

[Eder]

Would be awesome if tern has the option to choose how prefix number is generated when create a migration file.
To avoid migration conflicts, "rails like" approach is more simple and effective.
For example, instead generate a sequential number, tern would generate a timestamp numbered prefix, e.g. 20220512190701_create_foo

[Jack Christensen]

Timestamp migrations mean the order migrations are actually applied to production is non-deterministic and may never have even occurred once in development or testing.

In addition, it is conceptually much more complicated. Instead of the state of migrations being a single integer it becomes a boolean for every migration.

I've used them in Rails and it was a purposeful choice to avoid them here.

Take a look at #49. tern now has a renumber command to make renumbering conflicts relatively painless.

[Eder]

Thanks for reply! Actually the way that tern works in this case is a little intrusive in my opinion, conflicts must be resolved aside tern. And I don't think that timestamped migrations are bad. Even in a project with concurrent developers, they much probably won't modify the same domain/table, so the occurrence of conflicts related to execution order of migrations are low and the annoying task to rename files, make another commits, etc could be avoided.

[Massimo Costa]

My 2 cents here, the timestamp versioning has a potential problem well described here. Many tools use sequential versioning and some (goose is one of them) allow to have an hybrid approach (timestamp in development and sequence in production).

Honestly I agree that sequence versioning is safer and I prefer to have to fix issue in development instead of discover problems in production