django.db.migrations.exceptions.일관성 없는 마이그레이션역사
가 행할때실을 할 때.python manage.py migrateDjango 프로젝트에서 다음 오류가 발생했습니다.
Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "/home/hari/project/env/local/lib/python2.7/site- packages/django/core/management/__init__.py", line 363, in execute_from_command_line
utility.execute()
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 355, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 283, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/base.py", line 330, in execute
output = self.handle(*args, **options)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 86, in handle
executor.loader.check_consistent_history(connection)
File "/home/hari/project/env/local/lib/python2.7/site-packages/django/db/migrations/loader.py", line 298, in check_consistent_history
connection.alias,
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.
아래와 같은 사용자 모델이 있습니다.
class User(AbstractUser):
place = models.CharField(max_length=64, null=True, blank=True)
address = models.CharField(max_length=128, null=True, blank=True)
어떻게 하면 이 문제를 해결할 수 있을까요?
사용자 지정 사용자 모델을 사용하고 있으므로 다음 4단계를 수행할 수 있습니다.
- INSTALLED_APPS 설정에서 django.contrib.admin을 주석 처리합니다.
INSTALLED_APPS = [ ... #'django.contrib.admin', ... ]
- URL의 관리 경로를 주석으로 표시합니다.파이의
urlpatterns = [ ... #path('admin/', admin.site.urls) ... ]
- 그럼 실행
python manage.py migrate
- 완료되면 주석을 모두 취소합니다.
먼저 이 페이지의 대부분의 답변으로 문제를 해결해 보겠습니다.
Django의 마이그레이션 시스템을 올바르게 사용하는 경우 데이터베이스를 삭제할 필요가 없으며 마이그레이션이 실행된 후에는 삭제하지 않아야 합니다.
이제 가장 적합한 솔루션은 Django에 대한 경험, 마이그레이션 시스템에 대한 이해도, 데이터베이스의 데이터 가치 등 다양한 요소에 따라 달라집니다.
간단히 말해서 마이그레이션 오류를 해결할 수 있는 두 가지 방법이 있습니다.
핵 옵션을 선택합니다.경고: 혼자 작업하는 경우에만 선택할 수 있습니다.다른 사용자가 기존 마이그레이션에 의존하는 경우 해당 마이그레이션을 삭제할 수 없습니다.
- 모든 마이그레이션을 삭제하고 다음을 사용하여 새 집합을 재구성합니다.
python3 -m manage makemigrations이렇게 하면 마이그레이션의 종속성 또는 불일치 문제가 제거됩니다. - 전체 데이터베이스를 삭제합니다.이렇게 하면 실제 데이터베이스 스키마와 마이그레이션 기록을 기반으로 해야 하는 스키마 간의 불일치 문제가 제거되고 마이그레이션 기록과 이전 마이그레이션 파일 간의 불일치 문제가 제거됩니다.
InconsistentMigrationHistory에 대해 불평하고 있습니다. - 다음을 사용하여 데이터베이스 스키마 다시 만들기
python3 -m manage migrate
- 모든 마이그레이션을 삭제하고 다음을 사용하여 새 집합을 재구성합니다.
오류의 원인을 파악하고 해결합니다. (경험에 비추어 볼 때) 원인은 거의 틀림없이 어리석은 짓이기 때문입니다. (일반적으로 마이그레이션 시스템을 올바르게 사용하는 방법을 이해하지 못했기 때문입니다.)제가 일으킨 오류를 기준으로 세 가지 범주가 있습니다.
- 마이그레이션 파일과 일치하지 않습니다.이것은 여러 사람이 프로젝트를 진행할 때 매우 일반적인 현상입니다.당신의 변화가 충돌하지 않기를 바랍니다.
makemigrations --merge이 문제를 해결할 수 있습니다. 그렇지 않으면 누군가가 이 문제를 해결하기 위해 분기 지점으로 마이그레이션을 롤백해야 합니다. - 스키마와 마이그레이션 기록이 일치하지 않습니다.이를 관리하기 위해 다른 사용자가 데이터베이스 스키마를 수동으로 편집하거나 마이그레이션을 삭제했습니다.사용자가 마이그레이션을 삭제한 경우 변경 내용을 되돌리고 소리를 지르십시오. 다른 사용자가 마이그레이션에 의존하는 경우에는 마이그레이션을 삭제해서는 안 됩니다.데이터베이스 스키마를 수동으로 편집한 경우 변경 내용을 되돌린 다음 소리를 지릅니다. 장고는 다른 사용자가 아닌 데이터베이스 스키마를 관리하고 있습니다.
- 마이그레이션 기록과 마이그레이션 파일 간의 불일치.[이것이 바로 그
InconsistentMigrationHistory질문자가 겪고 있는 문제와 이 페이지에 도착했을 때 겪었던 문제].이를 관리하기 위해 누군가가 수동으로 조작했습니다.django_migrations테이블에 추가하거나 적용 후 마이그레이션을 삭제했습니다.이 문제를 해결하려면 불일치가 발생한 방법을 해결하고 수동으로 해결해야 합니다.데이터베이스 스키마가 올바르고 잘못된 것이 마이그레이션 기록인 경우 수동으로 편집할 수 있습니다.django_migrations이 문제를 해결하기 위한 표.데이터베이스 스키마가 잘못된 경우, 데이터베이스 스키마를 수동으로 편집하여 데이터베이스 스키마가 필요한 것과 일치하도록 해야 합니다.
- 마이그레이션 파일과 일치하지 않습니다.이것은 여러 사람이 프로젝트를 진행할 때 매우 일반적인 현상입니다.당신의 변화가 충돌하지 않기를 바랍니다.
문제에 대한 당신의 설명과 당신이 선택한 답변을 바탕으로 저는 당신이 혼자 일하고 있고, 장고에 처음이며, 당신의 데이터에 대해 신경 쓰지 않는다고 가정할 것입니다.그래서 핵 옵션이 당신에게 맞을 수도 있습니다.
만약 당신이 이 상황에 있지 않고 위의 글이 횡설수설한 것처럼 보인다면, 저는 장고 사용자의 메일링 리스트에 도움을 요청하는 것을 제안합니다.거기에는 여러분이 처한 특정한 혼란을 해결하는 데 도움을 줄 수 있는 매우 도움이 되는 사람들이 있습니다.
믿음을 가지세요, 핵 없이도 이 오류를 해결할 수 있습니다!
데이터베이스의 django_migrations 테이블이 불일치의 원인이므로 로컬 경로에서만 모든 마이그레이션을 삭제할 수 없습니다.
데이터베이스에서 django_migrations 테이블을 잘라낸 다음 마이그레이션을 다시 적용해야 합니다.작동해야 하지만 실행되지 않으면 마이그레이션을 다시 수행한 다음 마이그레이션합니다.
참고: 데이터를 백업하는 것을 잊지 마십시오.
이것은 장고 문서의 권장 사항에 따라 사용자 정의 사용자 모델을 추가한 후 새로운 프로젝트에서 발생했습니다.
새 프로젝트를 시작하는 경우 기본 사용자 모델로 충분하더라도 사용자 지정 사용자 모델을 설정하는 것이 좋습니다.
여기 문제를 해결하기 위해 제가 한 일이 있습니다.
- 데이터베이스 db.sqlite3을 삭제합니다.
- 앱/마이그레이션 폴더를 삭제합니다.
@jackson별로 임시로 django.contrib.admin을 주석 처리합니다.
INSTALLED_APPS = [
...
#‘django.contrib.admin’,
...
]
또한 관리 사이트를 URL로 주석 처리합니다.py:
urlpatterns = [
path('profile/', include('restapp.urls')),
#path('admin/', admin.site.urls),
]
경로('admin/')에 주석을 달지 않으면 "LookupError:실행 시 'admin' 레이블이 있는 설치된 앱이 없습니다.
python manage.py migrate
마이그레이션이 완료되면 위의 두 가지 설명을 모두 취소합니다.
이 문제를 올바르게 해결하는 방법을 소개합니다.
프로젝트 내부의 마이그레이션 폴더에서 다음 단계를 수행합니다.
- _pycache_ 및 0001_initial 파일을 삭제합니다.
- 루트 디렉터리에서 db.sqlite3를 삭제합니다(모든 데이터가 사라지도록 주의).
- 터미널 실행 시:
-
python manage.해적판 이주
python manage.파이 이주
Voila.
문제
django.db.migrations.exceptions.일관성 없는 마이그레이션기록: 마이그레이션 admin.0001_initial이 데이터베이스 'default'의 종속성 계정.0001_initial보다 먼저 적용됩니다.
따라서 먼저 admin(admin.0001_initial) 없이 데이터베이스를 마이그레이션할 수 있습니다.
후 .admin.0001_initial.
해결책
- settings.py 의 INSTALLED_APPs에서 'django.dll.admin'을 제거합니다.
- 명령 실행:
Python 관리.pymake 마이그레이션 앱 이름
Python 관리.py 마이그레이션 앱 이름
- settings.py 파일의 INSTALLED_APPs에 'django.dll.admin'을 추가합니다.
- 명령을 다시 실행합니다.
Python 관리.pymake 마이그레이션 앱 이름
Python 관리.py 마이그레이션 앱 이름
다른 단계를 수행하기 전에 데이터베이스를 백업합니다.다시 백업합니다.
사용자 지정 사용자 모델 코드를 제거하고 설정에서 사용자 지정 모델 및 앱을 비활성화한 후 다음을 수행합니다.
python manage.py dumpdata auth --natural-primary --natural-foreign > auth.json
python manage.py migrate auth zero # This will also revert out the admin migrations
그런 다음 사용자 지정 모델을 추가하고 설정에서 설정한 다음 앱을 다시 활성화합니다.이 앱에 아직 마이그레이션이 없는지 확인하십시오.
그러면:
python manage.py makemigrations <your-app>
python manage.py migrate
python manage.py loaddata auth.json # Assumes your user-model isn't TOO dissimilar to the standard one.
알았어!
설정에서 마이그레이션하기 전에 앱 관리자에게 설명하여 해결됩니다.파이의
django.contrib.admin
그리고 urls.py 에서,
('admin/', admin.site.urls)
마이그레이션 후 주석 달기
모든 항목을 삭제합니다.migrations 폴더,__pycache__,.pyc삭제된 파일:
find . | grep -E "(__pycache__|\.pyc|\.pyo$|migrations)" | xargs rm -rf
그런 다음, 실행:
python manage.py makemigrations
python manage.py migrate
기본 사용자 모델을 일부 변경하거나 추상 사용자에 의해 사용자 지정 사용자 모델을 만들 때 해당 오류가 발생하는 경우가 많습니다.
1: 슈퍼 사용자를 생성한 다음 로그인하려면 사용자 이름과 암호가 필요하지만 USERNAME_FIELD = 'email'을 변환한 경우 사용자 이름 필드가 이메일로 변환되어 사용자 이름과 암호로 로그인할 수 없습니다.
그리고 만약 당신이 다른 슈퍼 유저를 만들려고 한다면 그것은 이메일과 비밀번호만 요구할 것이고, 이메일과 비밀번호로 슈퍼 유저를 만든 후 당신이 관리자 패널에 로그인하려고 할 때만 그것은 어떠한 사용자 이름과 사용자 이름 필드가 필요하지 않기 때문에 그 오류를 던질 것입니다.
2: 마이그레이션 중에 사용자 지정 사용자 모델을 생성한 후 오류가 발생하므로 먼저 이를 해결하기 위해 설정에 AUTH_USER_MODEL = 'appname.custommodelname'(appname은 사용자 지정 사용자 모델을 정의한 앱 이름이고 사용자 지정 모델 이름은 사용자 지정 사용자 모델에 지정한 모델의 이름)을 추가합니다.py 3: 그런 다음 해당 사용자 지정 사용자 모델을 만든 앱의 마이그레이션 폴더를 삭제하고 프로젝트 4의 데이터베이스 db.sqlite3를 삭제합니다. 이제 마이그레이션 python manage를 실행합니다.pymake migrations appname(사용자 지정 사용자 모델을 정의한 앱 이름) 5: 그런 다음 pymake migration by python manage.py migrate 6: 이제 끝입니다.
저의 경우 문제는 파이테스트 시작과 관련이 있습니다. 제가 방금 변경했습니다.--reuse-db--create-dbPytest를 실행하고 다시 변경했습니다.이것이 나의 문제를 해결했습니다.
db.sqlite3 데이터베이스를 직접 삭제하면 새 데이터베이스가 자동으로 생성됩니다.고칠 수 있을 겁니다.
rm sqlite3.db
python manage.py makemigrations
python manage.py migrate
sqlite 파일을 삭제하거나 'flush manage.py flush' 데이터베이스를 실행한 다음 makemigrations 및 migration 명령을 각각 실행합니다.
새 장고 프로젝트를 만들고 실행할 때
python manage.파이 이주
Django는 기본적으로 auth_user 테이블 하나와 auth_user로 시작하는 테이블 두 개를 포함하여 10개의 테이블을 만듭니다.
AbstractUser에서 상속받은 사용자 지정 사용자 모델을 생성하려는 경우 다음과 같은 오류 메시지와 함께 이 문제가 발생합니다.
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.
전체 데이터베이스를 삭제하고 새 데이터베이스를 생성하여 이 문제를 해결합니다.그리고 이것은 제가 언급한 세 개의 테이블을 대체했습니다.
오류는 기본적으로 다음과 같습니다.
Migration "B" is applied before its dependency "A" on database 'default'.
Sanity Check: 먼저 데이터베이스를 열고 'django_migrations' 표의 레코드를 확인합니다.레코드는 연대순으로 나열해야 합니다(예: A, B, C, D...).
오류에 나열된 "A" 마이그레이션의 이름이 데이터베이스에 나열된 "A" 마이그레이션의 이름과 일치하는지 확인합니다.(이전에 마이그레이션 파일을 수동으로 편집하거나 삭제하거나 이름을 바꾼 경우에는 다를 수 있습니다.)
이 문제를 해결하려면 데이터베이스에서 마이그레이션 A의 이름을 변경하거나 파일 이름을 변경합니다.그러나 변경사항이 팀의 다른 개발자가 데이터베이스에 보유한 변경사항과 일치하는지 확인합니다(또는 변경사항이 프로덕션 데이터베이스의 변경사항과 일치하는지 확인).
의 INSTALLED_APPS중요해 보입니다.항상 최근 작업을 목록의 맨 위/시작에 두면 django.contrib.admin과 관련하여 항상 올바르게 로드됩니다.을 내작을시이동로작으업의 INSTALLED_APPS리스트가 나를 위해 이 문제를 고쳤습니다.쿤시의 솔루션이 효과가 있었던 이유는 다른 순서로 마이그레이션을 실행했을 수도 있습니다.
사용자 오류 외에도 이러한 문제를 야기할 수 있는 또 다른 이유가 있습니다. 즉, 마이그레이션 스퀴즈와 관련된 장고의 알려진 문제입니다.
Python 2.7 + Django 1.11에서 완벽하게 작동하는 일련의 마이그레이션이 있습니다. 중입니다.makemigrations또는migrate데이터베이스가 새로 다시 생성된 경우에도 (테스트 목적으로) 항상 작동해야 하는 등의 작업을 수행합니다.
그러나 프로젝트를 Python 3.6(현재 동일한 Django 1.11 사용)으로 이동하면서 동일한 마이그레이션이 처음 실행될 때만 제대로 적용되는 이유를 파악하려고 노력하고 있습니다.후에, 후에시, 라도도어를 하려는 시도가 수 .makemigrations 그냥 아면그냥니▁just.migrate오류가 발생합니다.
django.db.migrations.exceptions.InconsistentMigrationHistory
서 마이그레이션 이하는곳주곳.foo.0040-thing▁its▁▁before다ency▁is니▁depend됩foo.0038-something-squashed-0039-somethingelse(더 .)나머지는 훨씬 더 간단합니다.)
한동안 저를 괴롭히는 것은 왜 이것이 Python 3에서만 발생하는지입니다.DB가 실제로 일관성이 없는 경우에는 항상 이러한 현상이 발생해야 합니다.처음 적용했을 때 마이그레이션이 완벽하게 정상적으로 작동하는 것처럼 보인다는 것도 마찬가지로 혼란스러웠습니다.
(현재의 Q&A 스레드를 포함하여) 많은 검색을 한 후, 저는 앞서 언급한 장고 버그 보고서를 우연히 발견했습니다.우리의 스쿼시 이주는 실제로 사용되었습니다.b의 replaces 선(예):replaces = [(b'', 'foo.0038-defunct'),.......]
일단 제가 그것을 제거했을 때b의사접의 replaces라인 모든 것이 정상적으로 작동했습니다.
빈 데이터베이스에서 작업 중인 경우 다른 앱 마이그레이션 전에 빠른 수정을 통해 계정 앱에 대한 마이그레이션을 실행할 수 있습니다.
$ ./manage.py migrate account
그리고 나서:
$ ./manage.py migrate
수정 방법(마이그레이션 폴더 또는 전체 데이터베이스 삭제 안 함)
- 데이터베이스 백업
- INSTALLED_APPS 및 AUTH_USER_MODEL = '계정에서 앱을 주석 처리합니다.설정에 '사용자'가 있습니다.파이의
python manage.py admin zero- 2단계 실행 취소
python manage.py migrate
이 문제가 발생한 이유는 무엇입니까?
은 django에 합니다 ㅠㅠㅠㅠAUTH_USER_MODEL장고 프로젝트를 만들 때 기본 인증 모델입니다.
에 프로젝트 모델을 AUTH_USER_MODELdjango admin app은 마이그레이션을 django 인증 모델 종속성으로 적용합니다.그러나 해당 종속성을 변경한 경우 모형을 다시 마이그레이션하려고 합니다.따라서 여기서 문제가 발생합니다. 현재 사용자 모델인 종속성이 적용되기 전에 관리 모델이 적용됩니다.따라서 관리 모델 마이그레이션을 되돌린 다음 다시 시도해야 합니다.
먼저 모든 마이그레이션 및 db.sqlite3 파일을 삭제하고 다음 단계를 수행합니다.
$ ./manage.py makemigrations myapp
$ ./manage.py squashmigrations myapp 0001(may be differ)
이전 마이그레이션 파일을 삭제한 후 마지막으로
$ ./manage.py migrate
표준이 아닌 사용자 모델을 작성하려고 할 때 예외가 나타나면 해당 지침을 따릅니다.
해당 지침을 단계별로 따름으로써 문제가 해결되었습니다.
- auth와 동일한 사용자 지정 사용자 모델을 만듭니다.User(사용자)라고 부르고 db_table='auth_user'를 설정합니다(같은 테이블을 사용하도록).
- 모든 마이그레이션 폐기
- 새 마이그레이션 집합 재생성
- 닭 한 마리(두 마리)를 희생시키고 데이터베이스 백업도 만듭니다.
- django_migrations 테이블 잘라내기
- 새 마이그레이션 세트 가짜 적용
- db_table 설정 해제, 사용자 지정 모델 변경, 마이그레이션 생성, 적용
외부 키 제약 조건을 적용하는 데이터베이스에서 이 작업을 수행하는 것이 좋습니다.노트북의 SQLite에서 이것을 시도하지 말고 서버의 Postgres에서 작동하기를 기대하십시오!
settings.py 에서 AUTH_USER_MODEL을 설정하면 다음과 같습니다.
AUTH_USER_MODEL = 'custom_user_app_name.User'
마이그레이션 및 마이그레이션 명령을 실행하기 전에 이 행에 주석을 달아야 합니다.그러면 이 줄의 주석을 다시 달 수 있습니다.
새 프로젝트를 만들고 앱이 없으면 실행합니다.
python manage.py migrate
Django는 기본적으로 10개의 테이블을 만듭니다.
상고 고객 AbstractUser그런 다음 다음과 같은 문제가 발생합니다.
django.db.migrations.exceptions.일관성 없는 마이그레이션기록: 마이그레이션 admin.0001_initial이 데이터베이스 'default'의 종속성 계정.0001_initial보다 먼저 적용됩니다.
마지막으로, 전체 데이터베이스를 삭제하고 실행합니다.
Wagtail 2.0에서 2.4로 마이그레이션할 때 이 문제가 발생했지만, 타사 앱이 현재 버전 이후에 마이그레이션할 버전 이전에 마이그레이션을 중지할 때 몇 번 더 본 적이 있습니다.
이 경우 충격적으로 간단한 해결책은 다음과 같습니다.
./manage.py migrate
./manage.py makemigrations
./manage.py migrate
즉, 마이그레이션을 시도하기 전에 단일 마이그레이션을 실행합니다.
이 문제는 대부분의 경우 초기 마이그레이션 후 사용자 모델을 확장할 경우 발생합니다.Abstract 사용자를 확장할 때마다 e-메일, first_name 등 모델에 존재하는 기본 필드가 생성되기 때문입니다.
이마저도 장고의 모든 추상 모델에 적용할 수 있습니다.
따라서 이에 대한 매우 간단한 해결책은 새 데이터베이스를 생성한 후 마이그레이션을 적용하거나 [이 경우 모든 데이터가 삭제됩니다.]를 삭제한 후 마이그레이션을 다시 적용하는 것입니다.
이 문제가 해결되려면 데이터베이스를 에서 삭제한 다음 마이그레이션을 실행하고 다시 마이그레이션해야 합니다.
마이그레이션 폴더 및 db.sqlite3을 삭제하고 cmd python manage를 입력합니다.해적판 이주
django.db.migrations.exceptions.일관성 없는 마이그레이션사용자 지정 사용자 모델 생성에 대한 기록 #
저는 오늘 같은 문제를 겪었는데, 위의 솔루션 중 어떤 것도 작동하지 않았습니다. 그리고 나서 저는 제 지역의 Postgre에서 모든 데이터를 지우려고 생각했습니다.다음 명령을 사용하는 SQL 데이터베이스
-- Drop everything from the PostgreSQL database.
DO $$
DECLARE
q TEXT;
r RECORD;
BEGIN
-- triggers
FOR r IN (SELECT pns.nspname, pc.relname, pt.tgname
FROM pg_catalog.pg_trigger pt, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace AND pc.oid=pt.tgrelid
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pt.tgisinternal=false
) LOOP
EXECUTE format('DROP TRIGGER %I ON %I.%I;',
r.tgname, r.nspname, r.relname);
END LOOP;
-- constraints #1: foreign key
FOR r IN (SELECT pns.nspname, pc.relname, pcon.conname
FROM pg_catalog.pg_constraint pcon, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace AND pc.oid=pcon.conrelid
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pcon.contype='f'
) LOOP
EXECUTE format('ALTER TABLE ONLY %I.%I DROP CONSTRAINT %I;',
r.nspname, r.relname, r.conname);
END LOOP;
-- constraints #2: the rest
FOR r IN (SELECT pns.nspname, pc.relname, pcon.conname
FROM pg_catalog.pg_constraint pcon, pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace AND pc.oid=pcon.conrelid
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pcon.contype<>'f'
) LOOP
EXECUTE format('ALTER TABLE ONLY %I.%I DROP CONSTRAINT %I;',
r.nspname, r.relname, r.conname);
END LOOP;
-- indicēs
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind='i'
) LOOP
EXECUTE format('DROP INDEX %I.%I;',
r.nspname, r.relname);
END LOOP;
-- normal and materialised views
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind IN ('v', 'm')
) LOOP
EXECUTE format('DROP VIEW %I.%I;',
r.nspname, r.relname);
END LOOP;
-- tables
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind='r'
) LOOP
EXECUTE format('DROP TABLE %I.%I;',
r.nspname, r.relname);
END LOOP;
-- sequences
FOR r IN (SELECT pns.nspname, pc.relname
FROM pg_catalog.pg_class pc, pg_catalog.pg_namespace pns
WHERE pns.oid=pc.relnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pc.relkind='S'
) LOOP
EXECUTE format('DROP SEQUENCE %I.%I;',
r.nspname, r.relname);
END LOOP;
-- extensions (only if necessary; keep them normally)
FOR r IN (SELECT pns.nspname, pe.extname
FROM pg_catalog.pg_extension pe, pg_catalog.pg_namespace pns
WHERE pns.oid=pe.extnamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
) LOOP
EXECUTE format('DROP EXTENSION %I;', r.extname);
END LOOP;
-- aggregate functions first (because they depend on other functions)
FOR r IN (SELECT pns.nspname, pp.proname, pp.oid
FROM pg_catalog.pg_proc pp, pg_catalog.pg_namespace pns, pg_catalog.pg_aggregate pagg
WHERE pns.oid=pp.pronamespace
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast')
AND pagg.aggfnoid=pp.oid
) LOOP
EXECUTE format('DROP AGGREGATE %I.%I(%s);',
r.nspname, r.proname,
pg_get_function_identity_arguments(r.oid));
END LOOP;
-- routines (functions, aggregate functions, procedures, window functions)
IF EXISTS (SELECT * FROM pg_catalog.pg_attribute
WHERE attrelid='pg_catalog.pg_proc'::regclass
AND attname='prokind' -- PostgreSQL 11+
) THEN
q := 'CASE pp.prokind
WHEN ''p'' THEN ''PROCEDURE''
WHEN ''a'' THEN ''AGGREGATE''
ELSE ''FUNCTION''
END';
ELSIF EXISTS (SELECT * FROM pg_catalog.pg_attribute
WHERE attrelid='pg_catalog.pg_proc'::regclass
AND attname='proisagg' -- PostgreSQL ≤10
) THEN
q := 'CASE pp.proisagg
WHEN true THEN ''AGGREGATE''
ELSE ''FUNCTION''
END';
ELSE
q := '''FUNCTION''';
END IF;
FOR r IN EXECUTE 'SELECT pns.nspname, pp.proname, pp.oid, ' || q || ' AS pt
FROM pg_catalog.pg_proc pp, pg_catalog.pg_namespace pns
WHERE pns.oid=pp.pronamespace
AND pns.nspname NOT IN (''information_schema'', ''pg_catalog'', ''pg_toast'')
' LOOP
EXECUTE format('DROP %s %I.%I(%s);', r.pt,
r.nspname, r.proname,
pg_get_function_identity_arguments(r.oid));
END LOOP;
-- nōn-default schemata we own; assume to be run by a not-superuser
FOR r IN (SELECT pns.nspname
FROM pg_catalog.pg_namespace pns, pg_catalog.pg_roles pr
WHERE pr.oid=pns.nspowner
AND pns.nspname NOT IN ('information_schema', 'pg_catalog', 'pg_toast', 'public')
AND pr.rolname=current_user
) LOOP
EXECUTE format('DROP SCHEMA %I;', r.nspname);
END LOOP;
-- voilà
RAISE NOTICE 'Database cleared!';
END; $$;
그런 다음 마이그레이션을 위해 장고 명령을 실행할 수 있습니다.
python manage.py makemigrations
python manage.py migrate
그리고 그것은 절대적으로 효과가 있을 것입니다.감사해요.
이러한 단계도 작동할 수 있습니다.
- 전체 데이터베이스 삭제
- 새 마이그레이션 만들기
이 몇 가지 단계를 통해 문제를 해결할 수 있으며, 동일한 프로젝트에 여러 명의 기여자가 있을 때가 가장 좋습니다.
사용자 지정 사용자 모델을 사용하고 있으므로 먼저 주석을 달 수 있습니다.
INSTALLED_APPS = [
...
#'django.contrib.admin',
...
]
설치된_Apps 설정에 있습니다.그리고 댓글도.
urlpatterns = [
# path('admin/', admin.site.urls)
....
....
]
기본 URL에 있습니다.파이의
그럼 실행
python manage.py migrate.
완료 시 주석을 제거합니다.
'django.contrib.admin'
그리고.
path('admin/', admin.site.urls)
언급URL : https://stackoverflow.com/questions/44651760/django-db-migrations-exceptions-inconsistentmigrationhistory
'programing' 카테고리의 다른 글
| 트리거를 사용하지 않고 Oracle 자동 증가 (0) | 2023.06.18 |
|---|---|
| 로컬 XML 파일에서 테이블로 데이터를 로드할 때 MariaDB node.js 스크립트에서 ER_LOCAL_INFILE_WRONG_FILENAME 오류가 발생함 (0) | 2023.06.18 |
| C/C++: do-while(0)을 사용하는 방법; C4127과 같은 컴파일러 경고 없이 구성? (0) | 2023.06.13 |
| Oracle 10에서 잠금 제거 (0) | 2023.06.13 |
| SQLAlchemy에서 SQL 쿼리 인쇄를 예쁘게 포맷하는 방법 (0) | 2023.06.13 |