1. OpenREM
  2. OpenREM
  3. OpenREM
  4. Issues

Issues

Issue #399 resolved

Database migration file needs updating for changes since b13

Ed McDonagh
created an issue

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.

Comments (19)

  1. Ed McDonagh reporter

    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.

  2. Ed McDonagh reporter

    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.

  3. Ed McDonagh reporter

    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.

  4. Ed McDonagh reporter

    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.

  5. Ed McDonagh reporter

    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!

  6. Log in to comment