-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Establish on_delete for ForeignKey re Django update #2645 #2648
Establish on_delete for ForeignKey re Django update #2645 #2648
Conversation
Adds now required on_delete argument to all ForeignKey and OneToOneField definitions: in both model definitions and all prior migration files. The resulting migration files for storageadmin (default) and smart_manager were created via: - poetry run django-admin makemigrations storageadmin - poetry run django-admin makemigrations smart_manager
An rpm was build with these changes pre-merged:
And the resulting migrations look to have been applied: Default database (storageadmin)
And smart_manager
|
A test_pool and test_share were created and the share was then exported via Samba to create a chain of on_delete object instances. Deleting the pool did not result in any rockstor.log errors and the Web-UI behaved as expected. |
test migration from 5.0.2-0 via cli upgrade.5.0.2-0 was installed and setup from a prior wiped /opt/rockstor: which, given there is not .initrock initrock (rockstor-pre) will drop prior rockstor databases.
A cli upgrade was performed to 5.0.2-2648 (lan hosted test repo )
From this last test it appears we are failing to apply our migrations: however we have yet to re-run our initrock (rockstor-pre) where our migrations are applied.
|
Given an in-development fix associated with issue: Web-UI update fails to recreate venv #2652 We now have a successful Web-UI update from 5.0.1-0 to an rpm build from the product of this pr: resulting in a 5.0.2-2648 rpm. |
Adds now required on_delete argument to all ForeignKey and OneToOneField definitions: in both model definitions and all prior migration files. The resulting new migration files for storageadmin (default) and smart_manager were created via:
Fixes #2645
Testing
See referenced issue comments for test application of the resulting migration files. Otherwise this pull request is simply a pre-requisite for our next Django update, see issue #2625; and represents no functional change given we have explicitly added what was previously an implicit default behaviour.