Based on past experience with frameworks that use ordered migration files (Rails, etc.), most have switched away from using integer prefixes (1_foo.js) to UTC-timestamped prefixes (20171002150400_foo.js)
This solves two problems:
Sorting
Given two migration filenames:
1_foo.js
11_bar.js
Which migration is executed first? While not highly likely to cause problems, there's no guarantee that every piece of software will sort those in the same order.
Switching to a fixed-width, numeric prefix negates any ambiguity.
Parallel development
Imagine a scenario in which two developers (Dan and Jess) branch from a master commit at the same time and each generate the following migration files:
Dan: 4_dan_change.js
Jess: 4_jess_change.js
If it turns out Jess is a quicker developer and gets her migration merged first with Dan's getting merged second, it is very likely that Dan's migration will execute before Jess' migration which is likely not intended. Dan should have rebased/merged from master and ensured that his migration runs properly after Jess'.
Switching to UTC-timestamped, numeric prefixes significantly reduces the chances that a migration generated later in time will run before a migration generated earlier in time.
Important note
This does not solve all integration problems and migrations still need to be handled carefully. Even with timestamp-based migration naming, it is still possible to mess up the parallel development process, but it makes it much clearer who needs to adapt their migration to the other migrations.
Based on past experience with frameworks that use ordered migration files (Rails, etc.), most have switched away from using integer prefixes (
1_foo.js) to UTC-timestamped prefixes (20171002150400_foo.js)This solves two problems:
Sorting
Given two migration filenames:
1_foo.js11_bar.jsWhich migration is executed first? While not highly likely to cause problems, there's no guarantee that every piece of software will sort those in the same order.
Switching to a fixed-width, numeric prefix negates any ambiguity.
Parallel development
Imagine a scenario in which two developers (Dan and Jess) branch from a master commit at the same time and each generate the following migration files:
4_dan_change.js4_jess_change.jsIf it turns out Jess is a quicker developer and gets her migration merged first with Dan's getting merged second, it is very likely that Dan's migration will execute before Jess' migration which is likely not intended. Dan should have rebased/merged from master and ensured that his migration runs properly after Jess'.
Switching to UTC-timestamped, numeric prefixes significantly reduces the chances that a migration generated later in time will run before a migration generated earlier in time.
Important note
This does not solve all integration problems and migrations still need to be handled carefully. Even with timestamp-based migration naming, it is still possible to mess up the parallel development process, but it makes it much clearer who needs to adapt their migration to the other migrations.