- edited description
MIgration docs 0.10 to 1.0
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 behaviouron_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 moreForeignKey
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)
-
reporter -
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]
-
reporter We could craft an initial migration file to use. I’ll try that before upgrading testing.
-
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 todevelop
head to test the initial file. -
reporter 'initial' migration to use when migrating from 0.10 to 1.0. Refs
#813→ <<cset a9037d416aad>>
-
reporter Starting the migration docs. Refs
#813→ <<cset 7ff703ecd33d>>
-
reporter Need to get read the docs working again. Refs
#813→ <<cset d047a6f3e455>>
-
reporter Adding sphinx related libraries required for building docs. Refs
#813→ <<cset 4d572c0ed5ad>>
-
reporter Added postgresql binary to requirements. Added not about local_settings.py updating and creating Python 3 virtualenv. Refs
#813→ <<cset 13706c168800>>
-
reporter Attempt to correct code-block; adding note about updating celery, flower configs. Refs
#813→ <<cset 5162bfd99b9d>>
-
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…
-
reporter engine is now postgresql rather than postgresql_psycopg2 in settings. Refs
#813→ <<cset 7f52f2aaf344>>
-
reporter Using YAML anchors to improve the readability and maintainability of the pipelines file. Refs
#813→ <<cset eb60923a1512>>
-
reporter Switch to dev0 rather than a1. Refs
#813→ <<cset f61369777da4>>
-
reporter Merged in issue813dbmigration (pull request #359)
Refs
#813- more work to do→ <<cset d29f20928e34>>
-
reporter Refactored deployment script to use YAML anchors. Refs
#813→ <<cset c512b102d236>>
-
reporter Updating version 1 upgrade database migration with current further models changes. Refs
#813,#824,#744→ <<cset 00341d22eb42>>
-
reporter Fixing error with previous commit. Refs
#813,#824→ <<cset c02163315ede>>
-
reporter Starting upgrade to docker docs. Refs
#813[skip ci] docs only→ <<cset a7c1f57d2909>>
-
reporter Reverting changes to v1initial.py - it must be the release 0.10 database, but in Django 2.2 format. Upgrade process adds/alters all release 1.0 fields. Refs
#813,#824,#744→ <<cset 4670a7152cd5>>
-
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>>
-
reporter Updating Orthanc variables, adding web interface options. Reordering of release notes text. Refs
#813, #823 [skip ci] docs only→ <<cset 2e29ae1fe157>>
-
reporter Correcting mistakes David found. Refs
#813[skip ci] docs only→ <<cset 40124affc873>>
-
reporter Adding copying of skin dose map pickle files. Needs testing. Refs
#813[skip ci] docs only→ <<cset a1392b51f273>>
-
reporter Confirmed database name and password don't have to match previous. Added options to mean user doesn't either. Refs
#813[skip ci] docs only→ <<cset a78805cabb83>>
-
reporter Minor change to point out backup filename needs to match reality. Refs
#813[skip ci] docs only→ <<cset 42ef79b97b17>>
-
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>>
-
reporter - changed status to resolved
Should have been fixed with 9605cf24ea14
- Log in to comment