MIgration docs 0.10 to 1.0

Issue #813 resolved
Ed McDonagh created an issue

This is going to be fun…

In the process of upgrading dev.openrem.org to current develop. Went from 0.9 to 0.10, configured celery etc to do the migration. Repeated for demo.openrem.org (now up to date at last).

Installed a Python 3 virtualenv in dev.openrem.org folder, pip install -e source etc, added in psycopg-binary,

  • local_settings.py has to be manually updated
  • attempted database migration:

    File "/home/user/sites/dev.openrem.org/virtualenv/lib/python3.6/site-packages/django/core/management/base.py", line 364, in execute ('accumulated_xray_dose', models.ForeignKey(to='remapp.AccumXRayDose')), TypeError: __init__() missing 1 required positional argument: 'on_delete'

  • This relates to change in Django 2.0 requiring explicit argument on ForeignKey as to behaviour on_delete. All the models are updated, but the existing migration files are not. I’d usually propose wiping away all the migration files and creating a fresh fake initial, but that only works if the database and the models match (you do this, then upgrade and migrate the database).

  • This doesn’t really work when you are changing from Django 1.8, with the old models and Django 2.2 with the new ones.
  • Started by adding on_delete argument to the initial migration file, expecting to need to do it to lots of lines. Did the first one it complained about, then it was happy till:

    File "/home/user/sites/dev.openrem.org/source/openrem/remapp/migrations/0012_objectuidsprocessed.py", line 19, in Migration ('general_study_module_attributes', models.ForeignKey(to='remapp.GeneralStudyModuleAttr')), TypeError: __init__() missing 1 required positional argument: 'on_delete'

  • Updated that line in the same way, then:

    File "/home/deploy/sites/dev.openrem.org/source/openrem/remapp/migrations/0009_update_median_function.py", line 6, in <module> from django.db.models.loading import get_model ModuleNotFoundError: No module named 'django.db.models.loading'

  • But that module is not used, so removed the line, tried again:

    File "/home/user/sites/dev.openrem.org/source/openrem/remapp/migrations/0005_auto_20171013_2149.py", line 29, in Migration field=models.ForeignKey(related_name='ssde_wed_method', blank=True, to='remapp.ContextID', null=True), TypeError: __init__() missing 1 required positional argument: 'on_delete'

  • Fixed that, tried again. Now it is going back to 0001_initial.py with more ForeignKey missing positional arguments.

And so on. I’ll carry on going through in the morning, but suffice to say we need to rehearse this and work out a plan that can work for everyone.

It might be that we need an ‘upgrade’ release with Django 2.2 but the same models as release 0.10. We can then generate a fresh initial migration file and then upgrade again to the full release with the model changes which will now be happy…

(Updated description because formatting got messed up…)

Comments (28)

  1. Ed McDonagh reporter

    Had to install gunicorn too in the new virtualenv before it would start, surprisingly!

    [Aside: dev now up and running, next need to re-implement the pipeline and fabric commands so it updates automatically on commit to develop, then repeat for testing]

  2. Ed McDonagh reporter

    We could craft an initial migration file to use. I’ll try that before upgrading testing.

  3. Ed McDonagh reporter

    I think I need to start with a 0.10 install, upgrade to p3django2.2 branch, create a new fake migration, then do it again from 0.10 to develop head to test the initial file.

  4. Ed McDonagh reporter

    Made the foolish error of attempting this with testing.openrem.org without upgrading from 0.9.1 to 0.10 first, meaning the database fields introduced in 0.10 weren’t there and everything failed. However, I think the technique is good. Will have to start again with testing as I didn’t take a DB backup before I began…

  5. Ed McDonagh reporter

    Instructions for exporting from 0.10 install postgres and importing and upgrading to 1.0 docker install. Refs #813 [skip ci] docs only. Tested with export from Ubuntu production db Postgres v10 (Docker is Postgres v12)

    → <<cset 14661d55c983>>

  6. Ed McDonagh reporter

    Merged in issue813dbmigration (pull request #370)

    I think the database migration looks ok now, but testing it has shown up lots of other issues! Same needs to be done for non-docker Ubuntu instructions; will deal with them in issue ref #834.

    This PR fixes Issue ref #813

    → <<cset 9605cf24ea14>>

  7. Log in to comment