Reputation: 115
So far I've tried about anything the internet has given me on this problem and I still haven't solved it.
Python 3.6.1 - django 1.11.2 - virtualenv
I had a django project with two apps account
and app2
. Recently I decided to split them up into more appropriate apps as the project is growing. Now I have a total of 8 apps where account
got split up into user_auth
and user
, then I deleted account
. To tidy it up even more I moved all apps from the root folder to /apps/
.
So far, only user, user_auth, app2
is in use where app2
has been untouched.
The code in each separate file was split up, moved to the designated app and recoded to get imports from the correct paths.
To get a fresh start I delete the db.sqlite3 file, removed all *.pyc
files, deleted all __pycache__
folders and emptied the migrations
folders, making sure to keep all __init__.py
files.
Running python manage.py migrate
through a virtualenv gives me this output:
Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "H:\Programming\VirProjDir\lib\site-packages\django\core\management\__init__.py", line 363, in execute_from_command_line
utility.execute()
File "H:\Programming\VirProjDir\lib\site-packages\django\core\management\__init__.py", line 355, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "H:\Programming\VirProjDir\lib\site-packages\django\core\management\base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "H:\Programming\VirProjDir\lib\site-packages\django\core\management\base.py", line 330, in execute
output = self.handle(*args, **options)
File "H:\Programming\VirProjDir\lib\site-packages\django\core\management\commands\migrate.py", line 83, in handle
executor = MigrationExecutor(connection, self.migration_progress_callback)
File "H:\Programming\VirProjDir\lib\site-packages\django\db\migrations\executor.py", line 20, in __init__
self.loader = MigrationLoader(self.connection)
File "H:\Programming\VirProjDir\lib\site-packages\django\db\migrations\loader.py", line 52, in __init__
self.build_graph()
File "H:\Programming\VirProjDir\lib\site-packages\django\db\migrations\loader.py", line 274, in build_graph
raise exc
File "H:\Programming\VirProjDir\lib\site-packages\django\db\migrations\loader.py", line 244, in build_graph
self.graph.validate_consistency()
File "H:\Programming\VirProjDir\lib\site-packages\django\db\migrations\graph.py", line 261, in validate_consistency
[n.raise_error() for n in self.node_map.values() if isinstance(n, DummyNode)]
File "H:\Programming\VirProjDir\lib\site-packages\django\db\migrations\graph.py", line 261, in <listcomp>
[n.raise_error() for n in self.node_map.values() if isinstance(n, DummyNode)]
File "H:\Programming\VirProjDir\lib\site-packages\django\db\migrations\graph.py", line 104, in raise_error
raise NodeNotFoundError(self.error_message, self.key, origin=self.origin)
django.db.migrations.exceptions.NodeNotFoundError: Migration auth.0009_user_following dependencies reference nonexistent parent node ('account', '0002_contact')
So far, I've had no luck with these commands, making sure to remove all cached and *.pyc files inbetween:
python manage.py migrate
python manage.py makemigrations
python manage.py makemigrations <app_name>
python manage.py flush
python manage.py --fake
python manage.py --fake <app_name> zero
etc..
I don't get why ('account', '0002_contact')
keeps showing up even tho I've deleted about anything that's not directly related to my code.
A "containing text"-search reveals no account
what so ever.
Any idea where to look next?
Upvotes: 1
Views: 911
Reputation: 1
I recently had a problem similar to yours and I hope this can provide you with some direction to finding your solution.
My problem was only happening in my production environment.
Why? I will explain.
We use git for version control and whilst I was doing dev work on my local, I somehow included the app/migrations/0009.py
file to the .gitignore
file.
Long story short, I pushed the changes to the remote server and proceded on apply migrations but would constantly run into the issue you described.
After fiddling with manage.py and all migrations commands which inadvertently didn't yield any solution, I remembered that I hadn't looked to see if the missing dependency file was present.
The Solution:
I checked to see if the dependency file existed on the prod environment by running this command in the shell from my Django project folder.
$ ls app/migration
This revealed the non-existence of the dependency file required.
That's when I decided to inspect my local .gitignore
file and removed the line app/migrations/0009.py
I committed my local changes and pushed to the prod server. I then confirmed that the required file was present on the prod server by running this command.
$ ls app/migration
I ran
$ ./manage.py check
- and this time around the issue was gone.
All in all, check to make sure that the required dependency file does exist.
Upvotes: 0
Reputation: 11544
This is not the problem that the original poster had. However, when I had a similar error, this is how I fixed it.
In my case, I had the .py
extension in the dependency module name, like this:
dependencies = [
('dashboard', '0003_auto_20181024_0603.py'),
('auth', '__latest__'),
('contenttypes', '__latest__'),
]
I removed the .py
, changing it to this
('dashboard', '0003_auto_20181024_0603')
Upvotes: 0
Reputation: 115
Apparently django kept migration files within it's own module folder. This is what I did:
pip uninstall django
./Lib/site-packages
, deleted django
folder.*.pyc
files in my project.__pycache__
folders in my project.migrations
folders in my project (keep __init__.py
).pip install django==x.x.x
.python manage.py migrate
.python manage.py makemigrations <app_name>
.python manage.py migrate
.python manage.py runserver
.Upvotes: 1