django.db.migrations.exceptions.NodeNotFoundError: Migration social_auth.0004_auto_20160423_0400 dependencies reference nonexistent parent node (u'default', u'0003_alter_email_max_length')

[yeago]

django.db.migrations.exceptions.NodeNotFoundError: Migration social_auth.0004_auto_20160423_0400 dependencies reference nonexistent parent node (u'default', u'0003_alter_email_max_length')

Nobody?

Looking at https://github.com/omab/python-social-auth/blob/master/social/apps/django_app/default/migrations/0004_auto_20160423_0400.py#L11

kinda weird, did the app name change? look at the previous one.

https://github.com/omab/python-social-auth/blob/master/social/apps/django_app/default/migrations/0003_alter_email_max_length.py#L14

[CareyJWilliams]

Same issue here, did you ever work out what it was @yeago ?

[yeago]

I just hacked the migration manually to change the name and ran it.

On Aug 3, 2016 9:46 AM, "Carey Williams" notifications@github.com wrote:

Same issue here, did you ever work out what it was @yeago https://github.com/yeago ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/omab/python-social-auth/issues/962#issuecomment-237273138, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJVuphK3CJZmbe777u8pRt_Gu0A4t6vks5qcMMAgaJpZM4JUwzF .

[divonelnc]

I now have the following error: django.db.migrations.exceptions.NodeNotFoundError: Migration social_django.0005_auto_20160727_2333 dependencies reference nonexistent parent node ('social_django', '0004_auto_20160423_0400')

In social_django instead of default. Any idea?

[omab]

Fixed by https://github.com/python-social-auth/social-app-django/issues/2

[lukeaus]

I am still getting this error using social-auth-app-django==0.1.0 and social-auth-core==0.2.1 . Error: django.db.migrations.exceptions.NodeNotFoundError: Migration social_django.0004_auto_20160423_0400.py dependencies reference nonexistent parent node (u'social_django', u'0003_alter_email_max_length’)

Quite weird, cause that migration file 0003_alter_email_max_length.py is in the migrations folder.

[sharov]

Same issue. Django==1.9.7, python-social-auth[django]==0.3.3

[orzel]

same issue here, using Django 1.8 or 1.9, and social_auth_app_django-0.1.0.dist-info

[LordBastor]

One more over here with the same problem - using Django 1.8, migration 0005 doesn't seem to locate it's previous dependancy despite it being in the file and correctly named. Really weird.

[asgaines]

Yes, someone more knowledgeable: please help!

[dvdhpkns]

I'm having the same issue. @omab until this is resolved we are stuck on PSA...

[omab]

@dvdhpkns, did you try the steps on https://github.com/omab/python-social-auth/blob/master/MIGRATING_TO_SOCIAL.md#migrations ?

[dvdhpkns]

@omab, yes, I followed the steps. I am currently on python-social-auth==0.2.21, ran migrations and everything is working fine there. I run into trouble, however, when I try to update to the new library. I have install the new libs, updated all my settings, but when I run migrate I get the following:

django.db.migrations.graph.NodeNotFoundError: Migration social_django.0005_auto_20160727_2333 dependencies reference nonexistent parent node (u'social_django', u'0004_auto_20160423_0400')

Could this be related to the renaming of the app and change in the migration here: https://github.com/python-social-auth/social-app-django/commit/08b4fae4352f68a524d51a7e14767e5b093c4a73?

Thanks for your help!

[teeberg]

From what I understand, django adds to the django_migrations table when you apply a migration that replaces a previous one, even for the one that's replaced if it doesn't exist. So, assuming that you applied all previous migrations (which you did if you just upgraded from python-social-auth to the new social-auth-core), I think simply adding the missing migration rows manually like this is a clean fix:

INSERT INTO `django_migrations` (`app`, `name`, `applied`) VALUES ("social_auth", "0001_initial", NOW());
INSERT INTO `django_migrations` (`app`, `name`, `applied`) VALUES ("social_auth", "0003_alter_email_max_length", NOW());
INSERT INTO `django_migrations` (`app`, `name`, `applied`) VALUES ("social_auth", "0004_auto_20160423_0400", NOW());
INSERT INTO `django_migrations` (`app`, `name`, `applied`) VALUES ("social_auth", "0002_add_related_name", NOW());

[dvdhpkns]

@teeberg is there a way to do this in an automated way so that everyone on my team won't have the same migration issue?

[omab]

Do anybody have detailed steps to reproduce the situation? So far I wasn't able to do it on my end.

[teeberg]

@omab We were seeing this error:

Migration social_django.0005_auto_20160727_2333 dependencies reference nonexistent parent node (u'social_django', u'0004_auto_20160423_0400')

These migrations were applied to our database when that error was thrown:

|  10 | default                | 0001_initial                                           | 2015-04-30 17:09:37 |
| 172 | default                | 0002_add_related_name                                  | 2016-07-15 21:03:38 |
| 173 | default                | 0003_alter_email_max_length                            | 2016-07-15 22:52:54 |
| 174 | default                | 0004_auto_20160423_0400                                | 2016-07-15 22:53:09 |
| 203 | social_auth            | 0005_auto_20160727_2333                                | 2016-12-16 23:48:06 |
| 238 | social_django          | 0006_partial                                           | 2017-02-21 15:43:41 |
| 239 | social_django          | 0002_add_related_name                                  | 2017-02-21 17:23:38 |
| 240 | social_django          | 0003_alter_email_max_length                            | 2017-02-21 17:23:38 |
| 241 | social_django          | 0001_initial                                           | 2017-02-21 17:23:38 |
| 242 | social_django          | 0004_auto_20160423_0400                                | 2017-02-21 17:23:38 |
| 243 | social_django          | 0005_auto_20160727_2333                                | 2017-02-21 17:23:38 |

Adding these four to the table (without applying any changes) fixed it:

| 244 | social_auth            | 0001_initial                                           | 2017-02-21 22:34:01 |
| 245 | social_auth            | 0003_alter_email_max_length                            | 2017-02-21 22:34:01 |
| 246 | social_auth            | 0004_auto_20160423_0400                                | 2017-02-21 22:34:01 |
| 247 | social_auth            | 0002_add_related_name                                  | 2017-02-21 22:34:06 |

[teeberg]

@dvdhpkns @omab added a section about migrations here: https://github.com/omab/python-social-auth/blob/master/MIGRATING_TO_SOCIAL.md#migrations

Ideally, applying all migrations from python-social-auth would let you upgrade smoothly. If it doesn't, I think the best automated way forward is to make python-social-auth fix the migrations so that it does go smoothly :) Hopefully, the info about the migrations above can help @omab pinpoint the issue

[dvdhpkns]

@omab steps to repro:

1) Setup django project with old python social auth lib v. 0.2.13 2) Upgrade to v. 0.2.21, including running migrations 3) Change to new version of PSA with social-core and social-app-django (latest versions), run migrations

[dmchmk]

Hi! Looks like, the same issue here

I've done everything according to the instruction - https://github.com/omab/python-social-auth/blob/master/MIGRATING_TO_SOCIAL.md

But during the last step (manage.py migrate with updated code) i'm getting an error:

django.db.migrations.graph.NodeNotFoundError: Migration social_django.0004_auto_20170312_1222 dependencies reference nonexistent parent node (u'social_django', u'0003_alter_email_max_length')

But as I can see, all migration files are at their proper places:

ls -lah /var/venv/python27/local/lib/python2.7/site-packages/social_django/migrations
total 68K
drwxr-xr-x 2 root root 4.0K Mar 12 17:39 .
drwxr-xr-x 3 root root 4.0K Mar 12 17:36 ..
-rw-r--r-- 1 root root 4.3K Mar 12 17:36 0001_initial.py
-rw-r--r-- 1 root root 3.4K Mar 12 17:36 0001_initial.pyc
-rw-r--r-- 1 root root  783 Mar 12 17:36 0002_add_related_name.py
-rw-r--r-- 1 root root 1.3K Mar 12 17:36 0002_add_related_name.pyc
-rw-r--r-- 1 root root  690 Mar 12 17:36 0003_alter_email_max_length.py
-rw-r--r-- 1 root root 1.3K Mar 12 17:36 0003_alter_email_max_length.pyc
-rw-r--r-- 1 root root  567 Mar 12 17:36 0004_auto_20160423_0400.py
-rw-r--r-- 1 root root 1.1K Mar 12 17:36 0004_auto_20160423_0400.pyc
-rw-r--r-- 1 root root 1.3K Mar 12 17:22 0004_auto_20170312_1222.py
-rw-r--r-- 1 root root  513 Mar 12 17:36 0005_auto_20160727_2333.py
-rw-r--r-- 1 root root  989 Mar 12 17:36 0005_auto_20160727_2333.pyc
-rw-r--r-- 1 root root 1.1K Mar 12 17:36 0006_partial.py
-rw-r--r-- 1 root root 1.5K Mar 12 17:36 0006_partial.pyc
-rw-r--r-- 1 root root    0 Mar 12 17:36 __init__.py
-rw-r--r-- 1 root root  168 Mar 12 17:36 __init__.pyc

After some strace'ing I've discovered, that manage.py migrate is looking for migration files in absolutely different place for some reason:

11211 stat64("/var/venv/python27/local/lib/python2.7/site-packages/django/contrib/auth/migrations/0003_alter_user_email_max_length", 0xbedb3448) = -1 ENOENT (No such file or directory)
11211 open("/var/venv/python27/local/lib/python2.7/site-packages/django/contrib/auth/migrations/0003_alter_user_email_max_length.arm-linux-gnueabihf.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
11211 open("/var/venv/python27/local/lib/python2.7/site-packages/django/contrib/auth/migrations/0003_alter_user_email_max_length.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
11211 open("/var/venv/python27/local/lib/python2.7/site-packages/django/contrib/auth/migrations/0003_alter_user_email_max_lengthmodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)

Maybe, you can help me understand, why does it behaves in such way?

Thanks!

[dmchmk]

Used @teeberg's advice about manual inserts to db and it seems fixed the current process, but I'm afraid of possible further issues, that could appear when module development will move forward. Is it possible, how do you think?

[teeberg]

As far as I understand, adding those rows to the migrations table only made it look like it should've looked in the first place. So I don't expect any trouble because of it in the future. But please share if you run into any problems!

[dvdhpkns]

@teeberg @omab if adding these rows is necessary for migration, should we add a migration step to insert those rows? Not sure if that's even possible, but my concern is manually adding those rows and then having every other user of my project having to do the same and every new / future user having to learn this through tribal knowledge.

[teeberg]

Theoretically, you can have arbitrary python code in django migrations, so it should be doable to fix the migrations automatically by figuring out which ones are missing.

[cgthayer]

Following migration instructions and hitting same issue. Also had to manually insert the migrations (for sqlite use DATETIME() instead of NOW()). Seems to work now, but not feeling any confidence in this.

Migration social_django.0005_auto_20160727_2333 dependencies reference nonexistent parent node (u'social_django', u'0004_auto_20160423_0400

At this point I have only (there are only 112 users total, and only a few are using social auth): sqlite> select count() from social_auth_association; 0 sqlite> select count() from social_auth_code; 0 sqlite> select count() from social_auth_nonce; 0 sqlite> select count() from social_auth_partial; 0 sqlite> select count(*) from social_auth_usersocialauth; 12 sqlite> .schema social_auth_usersocialauth CREATE TABLE "social_auth_usersocialauth" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "provider" varchar(32) NOT NULL, "uid" varchar(255) NOT NULL, "user_id" integer NOT NULL REFERENCES "auth_user" ("id"), "extra_data" text NOT NULL); CREATE UNIQUE INDEX "social_auth_usersocialauth_provider_e6b5e668_uniq" ON "social_auth_usersocialauth" ("provider", "uid"); CREATE INDEX "social_auth_usersocialauth_e8701ad4" ON "social_auth_usersocialauth" ("user_id");

[yeago]

folks, in my august 3rd message I had indicated that a straightforward hack of the migration was all that was needed to proceed. I have since looked at the repository and the migrations directory has been replaced by a .py file. This is something of an experimental practice (at best). To anyone contending with this issue, I would say that you could #href="https://github.com/omab/python-social-auth/pull/980/files#diff-ea3ca5165c1c3aaac32d6d8299e3a9a9">go back to this diff and rename "default" to "social_auth" and then upgrade (or whatever) and then fake all migrations from there to a present-like state.

[cgthayer]

@yeago thanks, but in my case it was referencing 'social_django' not 'default' nor 'social_auth' (see error msg above). I inserted the "social_auth" migrations manually, but now I see I have newer 'social_django' entries as well (woops). It may be that my first packaging included "social-auth-app-django" then I realized I needed "python-social-auth[django]" as well. Since I don't have much experience with migrations, I've probably completely messed this up, though it seems to be working at the moment.

I imagine that we could put python code in the migration to detect if there were 'social_auth' or 'default' migrations that looked like a match, then use that dependency auto-magically, no?

sqlite> select * from django_migrations where app like '%social%' or app like '%auth%';
INSERT INTO table VALUES(2,'auth','0001_initial','2016-08-11 05:05:10.783228');
INSERT INTO table VALUES(28,'auth','0002_alter_permission_name_max_length','2016-08-11 05:05:13.715921');
INSERT INTO table VALUES(29,'auth','0003_alter_user_email_max_length','2016-08-11 05:05:13.763263');
INSERT INTO table VALUES(30,'auth','0004_alter_user_username_opts','2016-08-11 05:05:13.813902');
INSERT INTO table VALUES(31,'auth','0005_alter_user_last_login_null','2016-08-11 05:05:13.855558');
INSERT INTO table VALUES(32,'auth','0006_require_contenttypes_0002','2016-08-11 05:05:13.866386');
INSERT INTO table VALUES(33,'auth','0007_alter_validators_add_error_messages','2016-08-11 05:05:13.918604');
INSERT INTO table VALUES(59,'social_auth','0001_initial','2017-03-28 04:33:39');
INSERT INTO table VALUES(60,'social_auth','0002_add_related_name','2017-03-28 04:33:50');
INSERT INTO table VALUES(61,'social_auth','0003_alter_email_max_length','2017-03-28 04:33:56');
INSERT INTO table VALUES(62,'social_auth','0004_auto_20160423_0400','2017-03-28 04:34:03');
INSERT INTO table VALUES(68,'social_auth','0005_auto_20160727_2333','2017-03-28 04:37:01.988028');
INSERT INTO table VALUES(69,'social_django','0006_partial','2017-03-28 04:37:02.022577');
INSERT INTO table VALUES(74,'social_django','0002_add_related_name','2017-03-28 04:37:02.481073');
INSERT INTO table VALUES(75,'social_django','0003_alter_email_max_length','2017-03-28 04:37:02.487837');
INSERT INTO table VALUES(76,'social_django','0001_initial','2017-03-28 04:37:02.494446');
INSERT INTO table VALUES(77,'social_django','0004_auto_20160423_0400','2017-03-28 04:37:02.500878');
INSERT INTO table VALUES(78,'social_django','0005_auto_20160727_2333','2017-03-28 04:37:02.508305');

[Ivorforce]

After teeberg's solution didn't work, I did what https://github.com/omab/python-social-auth/commit/81c0a542d158772bd3486d31834c10af5d5f08b0 suggested:

1) Update social django on old machine 2) Run migrations 3) Re-import SQL database in new machine 4) Run migrations

That fixed it for me.

[shaib]

We ran into this issue; the cause was, as seems to be mentioned above, that we imported an old database which hadn't been migrated past python-social-auth==0.2.21 and tried to use it with a codebase using social-auth-app-django==1.2.0 and social-auth-core==1.4.0

We solved it by these steps: 1) pip install python-social-auth==0.2.21 2) replace social_django with social.apps.django_app.default in INSTALLED_APPS 3) python manage.py migrate 4) restore social_django instead of social.apps.django_app.default in INSTALLED_APPS 5) pip uninstall python-social-auth 6) python manage.py migrate

I hope this helps someone else.

[nihal111]

Thank you @shaib

[santosrennan]

I'm still in trouble. I've already done most of the requested steps, but I could not. django.db.migrations.graph.NodeNotFoundError: Migration social_django.0005_auto_20160727_2333 dependencies reference nonexistent parent node ('social_django', '0004_auto_20160423_0400')

[MayurBagul]

Hey Guys! im also facing this issue.

here is link to my problem scenario.:-

https://stackoverflow.com/q/61122442/11351226

Please help me with this because im not able to go further without solving this error .

[shaib]

@MayurBagul I posted an answer on your SO question; your problem doesn't seem to be related to this issue, or to python-social-auth at all.

[lalchan123]

I am still getting this error using social-auth-app-django==0.1.0 and social-auth-core==0.2.1 . Error: django.db.migrations.exceptions.NodeNotFoundError: Migration social_django.0004_auto_20160423_0400.py dependencies reference nonexistent parent node (u'social_django', u'0003_alter_email_max_length’)

Quite weird, cause that migration file 0003_alter_email_max_length.py is in the migrations folder.

[harshnative]

I GOT it working - django created migrations folder in my app , just delete it and run again

[MARKOTHEDEV]

okay i found the answers chances are u guys are using venv(python virtual enviroment) please delete that folder and delete all your migrations folder