Migrating to social_django zero doesn't empty django_migrations records in database

[infintesimal]

In a dev environment of mine, I am using social_django and everything is hunky dory. I like tearing down my app by typing ./manage.py migrate contenttypes zero This works as expected with, in my case, the following output

pg2) (xenial)steve@localhost:~/pg2$ ./manage.py migrate contenttypes zero
Operations to perform:
  Unapply all migrations: contenttypes
Running migrations:
  Rendering model states... DONE
  Unapplying social_django.0008_partial_timestamp... OK
  Unapplying social_django.0007_code_timestamp... OK
  Unapplying social_django.0006_partial... OK
  Unapplying social_django.0005_auto_20160727_2333... OK
  Unapplying social_django.0004_auto_20160423_0400... OK
  Unapplying social_django.0003_alter_email_max_length... OK
  Unapplying social_django.0002_add_related_name... OK
  Unapplying social_django.0001_initial... OK
  Unapplying dim.0002_auto_20180118_0701... OK
  Unapplying dim.0001_initial... OK
  Unapplying auth.0009_alter_user_last_name_max_length... OK
  Unapplying auth.0008_alter_user_username_max_length... OK
  Unapplying auth.0007_alter_validators_add_error_messages... OK
  Unapplying auth.0006_require_contenttypes_0002... OK
  Unapplying contenttypes.0002_remove_content_type_name... OK
  Unapplying auth.0005_alter_user_last_login_null... OK
  Unapplying auth.0004_alter_user_username_opts... OK
  Unapplying auth.0003_alter_user_email_max_length... OK
  Unapplying auth.0002_alter_permission_name_max_length... OK
  Unapplying auth.0001_initial... OK
  Unapplying contenttypes.0001_initial... OK

But then when I check the database, I get:

pg2=# select * from django_migrations;
 id |      app      |            name             |            applied            
----+---------------+-----------------------------+-------------------------------
 26 | social_django | 0003_alter_email_max_length | 2018-01-23 15:32:18.894896-08
 27 | social_django | 0004_auto_20160423_0400     | 2018-01-23 15:32:18.897215-08
 28 | social_django | 0001_initial                | 2018-01-23 15:32:18.900589-08
 29 | social_django | 0005_auto_20160727_2333     | 2018-01-23 15:32:18.904687-08
 30 | social_django | 0002_add_related_name       | 2018-01-23 15:32:18.911847-08
(5 rows)

This shows me that the django_social has forgotten to delete the appropriate records from django_migrations. As my django_social depends on my custom user model, a subsequent reqeust to ./manage.py migrate fails because social_django depends on my custom user model yet it still seems ot have migrations in the database.

I haven't traced the root cause of this yet, but it would be great to get an type of ./manage.py migrate social_django zero to actiually clear its corresponding database records.

Thanks, Steve

[infintesimal]

I found the root cause of the issue. The issue is the uses of the replaces attribute in migrations 0001...0005. That signifies that these migrations were squashed at some point, and when that is the case, the recorder self.migration_qs.filter(app=app, name=name).delete() in migrate backwards doesn't do anything. As this is a package, I will propose a pull request that deletes the 'replaces' lines, which is a moot point.

Because social_django depends on settings.AUTH_USER_MODEL reverting migrations causes a failure once the migrations are attempted to be "forwarded" again because these 5 db entries in the django_migrations table don't get deleted.

Steve

[nijel]

This issue can be reproduced in Django 3.2, but no longer exists in Django 4.0. So I'd say it's bug in Django which has been fixed.