Handle RC migrations

[mark-prins]

Is your feature request related to a problem? Please describe 👀

Currently if you install an RC version and initialise - if you then install a later RC which includes database migrations, you'll have to reinitialise the database.

This can take a considerable time (for example, if using cold chain) and so is a frustration for testers. The release schedule has us creating the RC builds at the end of the two development sprints, however for the upcoming release, the first feature is already done. We have the ability to create an RC build early which allows the QA team to spread the testing workload better. I don't want the difficulty of migration being a blocker in our ability to test effectively.

Describe the solution you'd like 🎁

Could the RC version be stored, and migrations grouped in batches according to RC version, within the major.minor version migration?

Describe alternatives you've considered 💭

Additional context 💌

Moneyworks Jobcode 🧰

[andreievg]

The main use case for disallowing RC upgrades is due to migration change, here are two use case, let's say we working on version 1.7.0

1 - RC version is made/used, but we decided that the field name is not correct, if we disallow RC upgrade this is quite easy (just change the name in the original RC version), if we do allow RC upgraded then we have to migrate the name changes in the RC build 2 - RC version i made/used, but our existing data migration was incorrect, similar to the above we have to re migrate the data (potentially, with original data already 'lost')

I was wondering if we can ask testers to re-initialise, or keep base sqlite datafile from previous version ? Maybe even build tools for this ? Or reference data files (considering things like cold chain data will get outdated, maybe it's actually better to have a reference data for it, with date updates)

[mark-prins]

I was wondering if we can ask testers to re-initialise

the issue says "This can take a considerable time (for example, if using cold chain) and so is a frustration for testers." it's not a deal breaker, no. but I find re initialising painful and best avoided.

or keep base sqlite datafile from previous version ?

tricky on android, and tricky if using postgres 😉 It would mean any changes made to the current (migrated) database would be lost / if they were sync'd to mSupply then things get tangled.

Perhaps we need something in the installer which warns / alerts the user if updating an RC version? Or we disallow this and force an uninstall and reinstall, which then encourages a re-initialisation? if you are using postgres it doesn't help - but it might solve the issue for testers? (while creating another issue, of having to re-init every time)

[andreievg]

Hmm, maybe we can set RC migration as 'breaking' ? And only those are considered un-upgradable ? The 'breaking' RC version will be manually decided and set by devs ? (when say we update schema between RC versions) ?

How do we flag and RC version as breaking ? We can probably add another trait method to Migration trait, that returns an array of 'broken' RC versions, and we disallow upgrading from them.

i.e. some breaking change in RC4, we add RC1, RC2, RC3 to the list of breaking versions, and we not allowed to upgrade from those to RC4, only RC4 upwards

[andreievg]

@jmbrunskill to confirm on RnD day and decide to keep in milestone or not