After upgrading to django 1.8 I'm recieving the error during migration:
ProgrammingError: relation "django_content_type" already exists
I'd be interested in the background behind this error, but more importantly, How can I resolve it?
After upgrading to django 1.8 I'm recieving the error during migration:
ProgrammingError: relation "django_content_type" already exists
I'd be interested in the background behind this error, but more importantly, How can I resolve it?
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
column "name" of relation "django_content_type" does not exist
–
Ottie 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
python manage.py collectstatic
command –
Promisee Django version 4.1.1
, postgresql-x64-14
, Windows 11 Home
- worked perfectly, even python manage.py collectstatic
was not necessary –
Resist I granted all privileges to the user on that specific database and it solved the issue.
I solved this issue on Django 2.2.7 or Django 3.0 hosted on Ubuntu 18.04 + Postgres 10.10 version.
I followed previous answer and found a better soloution:
The best way is to inspect migrations of all apps one by one. But how can you do that?
1-After restoring the database run this query on database:
SELECT * FROM public.django_migrations ORDER BY app,applied ASC
2-After running this query all migrations that applied to database will be shown with app name and apply date order .Accurately see each app in the result table and migrations(name column) and apply the following order for each app.
3-For example see account app name in the table, and migrations names recorded in the table, now run this command:
(virtualenv)python manage.py showmigrations [app_name]
see migrations list and compare last migrations for the app, if there was a difference between listed migrations and records in table, actually if you see list has more migrations than table records it's a time to migrate that app to apply changes to database using this command:
(virtualenv)python manage.py migrate [app_name] [found_migration_name]
4-If you found a migration record in the table and the app name was not listed after running showmigrations command, it means your project has now app labeled with that name, it's up to you to delete relevant table from database or if you want to install missed app or create missed model. Just be careful to delete migration records too if you want to delete app table from database, also be careful about dependencies.
5-Repeat steps 3,4 for other apps. That's it and enjoy your saved project.
© 2022 - 2024 — McMap. All rights reserved.
manage.py migrate
command that will work on both existing and new databases? – Sharecropper