Database migration file needs updating for changes since b13

[Ed McDonagh]

Currently if you upgrade from 0.6 to 0.7b15 using the instructions and the 0002_openrem_upgrade... file, the system won't work because of missing fields and tables.

That file was last updated in February, so it's likely that it didn't work for b14 or b15, but probably did for March's b13; about to check.

[Ed McDonagh]

Auto generated migration file from 0.7 b12 to b15. Refs #399

→ <<cset f5de7e9d459e>>

[Ed McDonagh]

Beta 13 didn't work either, but installing b12 and then upgrading from there to b15 did. I've added the migration file to stuff so that it can be used as a reference for what is missing.

[Ed McDonagh]

I think I've got all the changes. Refs #399

→ <<cset 35d97f8fc3f1>>

[Ed McDonagh]

Incidental to ref #399 but something I've wanted to do for ages!

→ <<cset 60f873035be9>>

[Ed McDonagh]

Renamed fresh install migration as per commit 60f8730 referred to in ref #399

→ <<cset 9766229b882a>>

[Ed McDonagh]

Changing the docs to reflect the file name changes in 9766229b882a9 and 60f873035be91 referred to in ref #399

→ <<cset c8119a73c4d7>>

[Ed McDonagh]

Currently gets stuck on the

        migrations.RemoveField(
            model_name='projectionxrayradiationdose',
            name='acquisition_device_type',
        ),

section, complaining that the field doesn't exist. Which it does in a 0.6 database.

I'm not sure what I'm missing at this stage.

[Ed McDonagh]

If I remove that phrase, the migration completes but the field is still there if I inspect the table afterwards

[David Platten]

I get the same error as you re removing the field. Can't see why it fails. Strange. Commenting out that part makes everything work OK.

[David Platten]

I should have said: I installed a fresh v0.6, and then followed the latest documents to the letter to upgrade to 0.7b15. They seemed to work well.

[Ed McDonagh]

I've worked out why, might not be worth doing anything about it. It won't be used either way.

I'll have bit more of a think about whether to try and fix it.

[Ed McDonagh]

Thanks for testing, and feedback on the docs.

[Ed McDonagh]

So I think the issue is that the way we are doing the migration is a bit unorthodox. Reviewing the migration from South docs you are supposed to ensure you have completed all your migrations under South, then remove the South stuff and do a fake migration that assumes that the database and the models are identical. Any changes from thereon get caught by makemigrations.

Our problem is that we want to ditch South and make database changes in one hit. Which mostly seems to work. But we can't remove a field from the database if the initial makemigration didn't think existed (because it was using the updated models).

I need to go back and check that field, but I think it was never populated, so it should be safe to leave it in migrated databases.

[Ed McDonagh]

Confirmed - the non-CID version was never used. It was briefly changed to be a foreign key, but this wasn't good for migrations on proper databases, so a new cid version was created and this one deleted. Even now, the value is used on import to determine what to try to extract, then never again!

[Ed McDonagh]

Removing removefield migration element that doesn't work. Refs #399

→ <<cset dc1ebcd2beda>>

[Ed McDonagh]

Tried migration again today with the field delete removed, works fine. Added to changes. Resolves #399

→ <<cset 45834759c7fc>>

[Ed McDonagh]

Added fix to migration file to release notes. Refs #399

→ <<cset 7fc5376efc53>>