[Maas-devel] HALP Migrations backporting

[Jeroen Vermeulen]

On 15/08/14 07:36, Julian Edwards wrote:
> On 15/08/14 10:30, Gavin Panella wrote:

>> Try creating a new data migration then plonking this code in, and see
>> what happens.
> 
> You can't do that I thought.  All migrations depend on the previous one,
> it's how South works.  (hence all the junk below the actual migration
> code you write)
> 
> Although having said that, if I make a new one, it might just work
> provided the sequence numbers can overlap, as the actual migration is
> idempotent.

As I recall this is a two-step migration: add ‘name’ column (schema
migration), populate it (data migration).  If we really needed only this
change, I'd backport it as follows:

1. Backport the model changes and the helper function.
2. Generate a new schema migration.
3. Generate a new data migration, and paste the migration code in.

The migration sequence numbers sound like a thorny issue though.  Only
one desperate idea springs to mind.

IIRC our experience is that South isn't as picky as we are about the
uniqueness of migration sequence numbers.  We do have a test for it, but
by then we already had a clash that had to be grandfathered in.  You
_can_ have two migrations with the same number and different names.

So maybe we could:

1. Backport trunk's migration #0099 to be an "extra" #0089.
2. Update #0099 to cope if the new column was already there.

The question is whether South will throw a tantrum about the missing
migration.  Maybe we could give trunk a blank #0089 in its place.  I'll
want another coffee before I go through the possible upgrade scenarios
though.


Jeroen