Swapping around migrations due to InconsistentMigrationHistory on acc…

[alextreme]

Problem that occurred on acceptance environments with v1.17.0 which I switched around on v1.17.1. This was most likely due to the fact that we delayed removing the statustranslation table to 1.17

[swrichards]

If this is only a question of an inconsistent migration state on acceptance, would it be an option to address that inconsistency directly instead of altering the migrations in-repo, doing something like:

1. Using migrate --fake to mark all in-repo migrations applied on acceptance
2. Assuming the database state has not yet applied the migration, we can then manually fetch the migration SQL from migrate.py sqlmigrate openzaak {0047|0048} and apply it directly in the dbshell (which would ignore the dependencies). The migrations are fairly simple (single line statements in each case) and do not depend on each other.

[alextreme]

This would be sufficient if all we have are SaaS environments (production has the same issue where 0047 is missing).

However we also have Dimpact-installed environments that need a clean migration path between releases, these are done with our Docker image but we don't have much of a say how and when a new version of OIP is installed. And we also have separate installs managed by Sjoerd using our Docker image separate from our SaaS installs. The main thing we could do is mention the steps you say in the release notes, but it wouldn't be easy for them.

So this PR is to avoid future upgrade problems and also a reminder that leaving a PR + migration out of a release will cause headaches during future releases. Of course, doing a squash would avoid confusion for new installs and allow us to clean up this history in due time.

[pi-sigma]

@alextreme Thanks for the explanation, that makes sense! Let's discuss the option of squashing migrations on Monday.

[swrichards]

Clear,, thanks!