on one of the recent technical committees, we have discussed an issue relating to the database migrations and using timestamps as versions for those migrations. As a summary, due to common conflicts in previous versions of OpenLMIS using serial versions, v3 decided to use timestamps to version migrations. A downside to that is that files can be committed “out of order”. This means if I generate my migration with a given timestamp, and someone else does it later but commits their changes earlier, I’ll be committing a migration that has an earlier version. You can also read the summary here: https://openlmis.atlassian.net/wiki/spaces/OP/pages/494436939/2019-01-08+TC+Meeting+notes
As I’ve stated on the tech call, using timestamps was a mistake in my eyes. Timestamps indeed do prevent the conflicts with identical versions, but they allow for committing migrations out of order, which we don’t want. Using serial versions would ensure that we always commit in order, even though, we would need to handle the conflicts (which in v3 aren’t that common, since we have each microservice handling their own migrations).
Now, I don’t think this is that a big deal and migration tests give us a little more confidence that migrations work, even if committed out of order. Moreover, special care needs to be applied when committing files early after a release so that no migrations are added with timestamps preceding latest one from the released version. Doing that would result in this migration never getting applied on the production server with the next release.
For now, we have added a warning that is served as a comment in generated migration files, to always make sure that the added file has the latest timestamp. I’ll welcome any comments on whether we should be doing anything else to make sure we don’t introduce migrations with incorrect versions, or if the current approach seems to be enough to mitigate the risk.