django.db.migrations.exceptions.InconsistentMigrationHistory error handling

Introduction

When I was doing web development with Django, the Migration error took quite a while, so I'll leave the details of how I dealt with it.

environment

Mac Catalina 10.15.6 Python 3.7 PostgreSQL 10.14 Django 2.2.2

Migration makemigrations $ python manage.py makemigrations django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency user.0001_initial on database 'default' The error seems to occur if you do python manage.py makemigrations even once before applying the CustomUser model ...

migrate $ python manage.py migrate RuntimeError: Model class django.contrib.sites.models.Site doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS. Of course, migrate didn't work either.

Check the current Migrations status

$ python manage.py showmigrations

If you get an error with this, it means that you have not been able to Migrate in the first place.

Coping

Action 1

First, delete all files other than __init__.py directly under migrations of each application.

Then comment out the'django.contrib.admin'part at the top of INSTALLED_APPS in settings.py.

＃*****　settings.py　********

$ INSTALLED_APPS = [
    # 'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'accounts'
]

AUTH_USER_MODEL = 'accounts.CustomUser'

In addition, comment out the admin part of ʻurl patterns in ʻurls.py.

#*****  urls.py  *******

from django.contrib import admin
from django.urls import path
from django.urls.conf import include

urlpatterns = [
   # path('admin/', admin.site.urls),
]

Now let's do migrate once. Hopefully it will pass.

Action 2

In the same way as [Action 1](## Action 1), delete all files except __init__.py directly under migrations of each application.

Delete the entire database and recreate it

In fact, I couldn't fix the error with [Action 1](## Action 1), so I succeeded in make migrations and migrate by rebuilding the database in this way. Here, postgresql @ 10 is used.

For the database, click here (https://qiita.com/kanzaki0507/items/12a2ef0b778250d699bd)

Check database

$ psql -l

                             List of databases
 Name      |  Owner  | Encoding |   Collate   |    Ctype    |  Access 
                                                           |  privileges  
---------------+---------+----------+-------------+-------------+---------
 postgres   | kanzaki | UTF8   | en_US.UTF-8 | en_US.UTF-8 | 
 app_name   | kanzaki | UTF8   | en_US.UTF-8 | en_US.UTF-8 | 
 template0  | kanzaki | UTF8   | en_US.UTF-8 | en_US.UTF-8 | =c/kanzaki  +
            |         |        |             |             | kanzaki=CTc/ 
            |         |        |             |             | kanzaki
 template1  | kanzaki | UTF8   | en_US.UTF-8 | en_US.UTF-8 | =c/kanzaki  +
            |         |        |             |             | kanzaki=CTc/ 
            |         |        |             |             | kanzaki
(4 rows)

Delete the database

$ dropdb app_name 

Make sure the database has been deleted

$ psql -l

                             List of databases
 Name      |  Owner  | Encoding |   Collate   |    Ctype    |  Access 
                                                           |  privileges  
---------------+---------+----------+-------------+-------------+---------
 postgres   | kanzaki | UTF8   | en_US.UTF-8 | en_US.UTF-8 | 
 template0  | kanzaki | UTF8   | en_US.UTF-8 | en_US.UTF-8 | =c/kanzaki  +
            |         |        |             |             | kanzaki=CTc/ 
            |         |        |             |             | kanzaki
 template1  | kanzaki | UTF8   | en_US.UTF-8 | en_US.UTF-8 | =c/kanzaki  +
            |         |        |             |             | kanzaki=CTc/ 
            |         |        |             |             | kanzaki
(3 rows)

Rebuild database

$ brew services start postgresql@10
$ create app_name

makemigrations & migrate $ python manage.py migrate Operations to perform: Apply all migrations: account, accounts, admin, auth, contenttypes, diary, sessions, sites Running migrations: Applying contenttypes.0001_initial... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0001_initial... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying auth.0007_alter_validators_add_error_messages... OK Applying auth.0008_alter_user_username_max_length... OK Applying auth.0009_alter_user_last_name_max_length... OK Applying auth.0010_alter_group_name_max_length... OK Applying auth.0011_update_proxy_permissions... OK Applying accounts.0001_initial... OK Applying account.0001_initial... OK Applying account.0002_email_max_length... OK Applying admin.0001_initial... OK Applying admin.0002_logentry_remove_auto_add... OK Applying admin.0003_logentry_add_action_flag_choices... OK Applying diary.0001_initial... OK Applying sessions.0001_initial... OK Applying sites.0001_initial... OK Applying sites.0002_alter_domain_unique... OK Did you succeed?

Summary

This time, I've summarized a part of the article that I was really into when developing the Web with Django. I was able to migrate by rebuilding the DB, but I wrote it because there weren't many articles showing this method. I wanted to let you know that this method can also be solved.

reference

Django always uses the CustomUser model! Talk What to do if Django custom user migration fails