Migration from 2.x to 3.x leaves `registration` table in database
pjrobertson opened this issue · comments
django-registration 3.x no longer uses the model-based approach, or the table registration_registrationprofile in the database. However, upgrading from 2.x to 3.x leaves that table in the database. That means, if you go to delete a User object, you're presented with the following error:
IntegrityError at /admin/url/to/view/
update or delete on table "myapp_usertable" violates foreign key constraint "registration_registrationprofile_user_id_fkey" on table "registration_registrationprofile"
DETAIL: Key (id)=(123) is still referenced from table "registration_registrationprofile".
3.x versions of django-registration should add a migration that either sets on_delete=models.CASCADE or just removes the registration_registrationprofile table all together. See #93 for some notes on this. The issue with that change is that it edited an existing migration, so would only applied to new installations. Those who'd already installed django-registration would never see this migration.
The correct behaviour would have been to edit the models.py file, then run makemigrations.
I 'fixed' my issue by just blindly deleting the table in the DB:
drop table registration_registrationprofile;I have no idea of the implications of this though. If it's fine, then this should be added as a migration to django_registration>=3.0
The problem with adding a migration for this is that some people might want to keep a historical table around with the data, and adding a migration more or less forces that table and all its data to drop at the next run of manage.py migrate. So I don’t think I’ll be adding a migration to drop that table. Documenting what to do with it in the upgrade notes is a possibility, though.
Keeping the table around makes sense, but in that case I think the table should decouple itself from the user model table (somehow removing the foreign key requirement on the). Another solution would just be to add an on_delete=models.SET_NULL for the RegistrationProfile model.
Basically, the issue that I hope we can solve is: if I try to delete a user after upgrading to django_registration>=3.0, I should still be able to delete.
The bigger problem is that as of 3.0, django-registration itself no longer ships any models or migrations at all. Adding them at this point would just introduce confusion for people who have already been on 3.x versions for several years (django-registration 3.0 was released in 2018) and would wonder why there are suddenly migrations. So again, I don't think django-registration will be adding a migration at this point. Installations that run into issues can manually generate their own migration to do what they want with the table -- whether that's dropping it, changing the ON DELETE behavior, or something else entirely.
I ultimately 'solved' this problem without deleting the registrationprofile table by dropping the foreign key requirement:
alter table registration_registrationprofile drop constraint registration_registrationprofile_user_id_fkey;
Perhaps this can be added to the docs?