Migrations failure about social-app-django

[koniiiik]

I could reproduce the same error with a pre-existing database from before the reorganization, where migrations 0001 ­– 0004 were applied with default as the appname.

After running update django_migrations set app='social_django' where app='default'; in a dbshell, showmigrations is capable of finishing successfully, but it still shows all social_django migrations as not applied (even though the first four are already applied). In this state, obviously, running migrate leads to an error, because it tries to apply all of them from the beginning, but the tables are already there.

The solution (in my situation) is to run migrate --fake social_django 0004, which adds entries to django_migrations for all already-applied migrations for appnames default and social_auth as well. So in the end, I have entries in the django_migrations table for all of the already-applied migrations for all three appnames: default, social_auth, and social_django. At this point migrations work correctly for me again.

I did some more digging, and it looks like the problem here is that the replaces attribute of a Django migration has a different meaning than what is assumed in the social_django package. This does not appear to be documented (or at least, I didn't find it in the docs), but https://github.com/django/django/blob/f582db1296cc18e2ff49846c9be4ad999759adcc/django/db/migrations/migration.py#L39-L42 sheds a little bit of light on the problem.

In short, the way replaces is used in this package seems to be along the lines of “Consider this migration applied if any of these two original migrations has been applied before,” whereas the actual meaning as understood by Django is “This migration is a replacement for the entire sequence of these two original migrations.” So, if Django only sees one of the original migrations being applied, but not the other one, it assumes the replacement is not yet applied either. And conversely, when the replacement is being applied, all of the originals get recorded, too, because there might be some other migrations elsewhere that depend on some of the originals. Which also means that if any of the original migrations is missing in the database, the replacement cannot be considered applied either.

Not sure what the way forward would be, though. I guess removing one of the two entries in replaces in all migrations would be necessary, and also documenting that a manual migrate --fake will be required in certain situations. As far as I understand, Django does not provide any more straight-forward automatic upgrade path for situations like this (but I may be wrong).

[omab]

I can't seem to reproduce this, do you have any extra details?

[black3r]

Considering the definition of replaces attribute, the real issue seems to be with the 5th migration having ('default', '0005_auto_20160727_2333'), in replaces, because that migration didn't exist while the migrations were applied with appname default.

When migrating my application from 0.2.21 to the new social app structure, no errors were thrown when running python manage.py migrate, but the 5th migration for social_django remains "unapplied" (there is no record for it in django_migrations table), and trying to install it manually by running python manage.py migrate social_django 0005 results in an error saying: django.db.migrations.exceptions.NodeNotFoundError: Node ('social_django', '0005_auto_20160727_2333') not a valid node

The issues with applying migrations 0001-0004 can be resolved with updating to 0.2.21 before updating to the version after the second application rename (which should be mentioned in the migration guide though)

(My production databases using python social auth version 0.2.21 contain default migrations 0001-0004 and social_auth migrations 0001-0005)

[anzellai]

I'm having the same trouble migrating from PSA 0.3.3.
I actually downgraded to 0.2.21 (as with what @black3r suggested above) and applied the migrations 0001 - 0004, then I have to bypass/comment out the replaces migrations 0005 to upgrade to current "social_core" & "social_django".

[roosmaa]

Hit the same snag. Guess I upgraded to new structure too early. For me the problem was the non-existing default 0005 migration. Fixed by doing:

$ python manage.py dbshell
=> INSERT INTO django_migrations(app, name, applied) VALUES('default', '0005_auto_20160727_2333', NOW());

After that the migrate command ran successfully.

[nijel]

Should be fixed by #25

[omab]

Closing since #25 is merged, reopen if needed. Thanks @nijel.