137
Initial migrations on a project can sometimes be troubleshot using –fake-initial
python manage.py migrate --fake-initial
It’s new in 1.8. In 1.7, –fake-initial was an implicit default, but explicit in 1.8.
From the Docs:
The –fake-initial option can be used to allow Django to skip an app’s initial migration if all database tables with the names of all models created by all CreateModel operations in that migration already exist. This option is intended for use when first running migrations against a database that preexisted the use of migrations. This option does not, however, check for matching database schema beyond matching table names and so is only safe to use if you are confident that your existing schema matches what is recorded in your initial migration.
https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-option—fake-initial
11
I solved this issue on Django 2.2.7 or Django 3.0 hosted on Ubuntu 18.04 + Postgres 10.10 version.
- Restore the database in Postgres database (used pgAdmin tool for this)
- (virtualenv)python manage.py loaddata dumpfile.json
- Dropping django_migrations table from database (used pgAdmin tool for this)
- (virtualenv)python manage.py makemigrations
- (virtualenv)python manage.py migrate –fake
- (virtualenv)python manage.py migrate
- (virtualenv)python manage.py collectstatic
- (virtualenv)python manage.py runserver 0.0.0.0:8000
- [Django]-Django : How can I find a list of models that the ORM knows?
- [Django]-How do I use CSS in Django?
- [Django]-Django FileField: How to return filename only (in template)
- [Django]-Django REST Framework – Separate permissions per methods
- [Django]-Django 1.7 – makemigrations not detecting changes
- [Django]-Django debug display all variables of a page