Migrations development

Migration Hell

This page collects a bunch of ideas I've been going over for how to support migrations, particularly where there is a type hierarchy.

Let A, B(A), C(B), D(A) be classes where brackets indicate inheriting from.

Here is a list of some migration types that the system should support:

1. B(A) becomes B with no parent and no members as copied over.

This is relatively easy as even if there are unnecessary members in the saved state, B should be able to load old versions by just ignoring them.

2. Assume B and D contain a name member that had previous been migrated from being called person_name. This is then unified and moved into A such that they now both inherit it.

We cannot perform this migration on A as it should not know about the existence of B or D, so A would just set the corresponding entry in the saved state to None. Migrations can be added to B and D to set the name field to the name they store however, this is fragile as a new version of A may appear containing a different label (not name) or even get rid of it entirely. If all migrations are applied to A first then the migrations on B and D would no longer work.

3. B(A) becomes B by copying all members and methods from A.

If we can copy over the member definitions such that they point to the same state variable in the record then this will continue to work without any migration

4. Migrations where a name is shadowed e.g. A contains name as well as B. This works fine, until A is migrated to remove name (or rename it to something else) which will cause B to stop working.

Possible solutions

There is an argument to be made that the saved state variables of a class should be private and therefore subclasses cannot make any use of knowledge about their existence.