Migration from 2.x to 3.x leaves `registration` table in database about django-registration

[pjrobertson]

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

[ubernostrum]

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.

[pjrobertson]

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.

[ubernostrum]

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.

[pjrobertson]

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?