django.db.dll 파일ProgrammingError: 관계가 이미 있습니다.

django.db.dll 파일ProgrammingError: 관계가 이미 있습니다.

새 django 프로젝트(즉, 테이블이 데이터베이스에 아직 존재하지 않음)를 위해 테이블을 설정하려고 합니다. django 버전은 1.7이고 db 백엔드는 Postgre입니다.SQL. 프로젝트 이름은 crud입니다.마이그레이션 시도 결과는 다음과 같습니다.

python manage.py makemigrations crud

Migrations for 'crud':
  0001_initial.py:
    - Create model AddressPoint
    - Create model CrudPermission
    - Create model CrudUser
    - Create model LDAPGroup
    - Create model LogEntry
    - Add field ldap_groups to cruduser
    - Alter unique_together for crudpermission (1 constraint(s))

python manage.py migrate crud

Operations to perform:
  Apply all migrations: crud
Running migrations:
  Applying crud.0001_initial...Traceback (most recent call last):
  File "manage.py", line 18, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 377, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 338, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py", line 161, in handle
    executor.migrate(targets, plan, fake=options.get("fake", False))
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/executor.py", line 68, in migrate
    self.apply_migration(migration, fake=fake)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/executor.py", line 102, in apply_migration
    migration.apply(project_state, schema_editor)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/migration.py", line 108, in apply
    operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
  File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/operations/models.py", line 36, in database_forwards
    schema_editor.create_model(model)
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/schema.py", line 262, in create_model
    self.execute(sql, params)
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/schema.py", line 103, in execute
    cursor.execute(sql, params)
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py", line 82, in execute
    return super(CursorDebugWrapper, self).execute(sql, params)
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py", line 66, in execute
    return self.cursor.execute(sql, params)
  File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 94, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py", line 66, in execute
    return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "crud_crudpermission" already exists

마이그레이션 파일의 몇 가지 주요 내용:

dependencies = [
    ('auth', '0001_initial'),
    ('contenttypes', '0001_initial'),
]
    migrations.CreateModel(
        name='CrudPermission',
        fields=[
            ('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
            ('_created_by', models.CharField(default=b'', max_length=64, null=True, editable=False, blank=True)),
            ('_last_updated_by', models.CharField(default=b'', max_length=64, null=True, editable=False, blank=True)),
            ('_created', models.DateTimeField(null=True, editable=False, blank=True)),
            ('_last_updated', models.DateTimeField(null=True, editable=False, blank=True)),
            ('domain', models.CharField(max_length=32, choices=[(b'town', b'Town'), (b'boe', b'BOE'), (b'police', b'Police')])),
            ('ldap_group', models.CharField(max_length=128, verbose_name=b'LDAP group')),
            ('can_add', models.BooleanField(default=False, verbose_name=b'add')),
            ('can_change', models.BooleanField(default=False, verbose_name=b'change')),
            ('restrict_change_to_own', models.BooleanField(default=False)),
            ('can_delete', models.BooleanField(default=False, verbose_name=b'delete')),
            ('restrict_delete_to_own', models.BooleanField(default=False)),
            ('models', models.ManyToManyField(to='contenttypes.ContentType', null=True, blank=True)),
        ],
        options={
            'verbose_name': 'CRUD permission',
        },
        bases=(models.Model,),
    ),
    migrations.AlterUniqueTogether(
        name='crudpermission',
        unique_together=set([('ldap_group', 'can_add', 'can_change', 'can_delete', 'domain')]),
    )

,

크루드 앱은 실제로 아무것도 할 의도는 없지만, 다른 앱을 사용하기 때문에 그 앱에서 마이그레이션하려고 하면 위의 문제가 발생합니다.

저는 비슷한 문제를 가진 사람들의 웹에서 다른 예들을 찾았지만, 그들의 경우는 적용되지 않는 것 같습니다. 왜냐하면

1. 문제는 하나의 열뿐만 아니라 전체 관계에 영향을 미칩니다.
2. 다중 상속을 사용하지 않습니다.

다음으로 근본적인 문제를 찾으려면 어디를 살펴봐야 합니까?

이것은 꽤 잘 작동합니다.

./manage.py migrate --fake default

https://docs.djangoproject.com/en/2.2/ref/django-admin/ #옵션-페이크페이크

도python manage.py migrate --fake맨 처음에

https://docs.djangoproject.com/en/3.2/ref/django-admin/ #django-admin-messages

기존 모델에 몇 개의 새로운 필드를 추가했을 때도 비슷한 문제에 직면한 적이 있습니다.저는 장고 1.9를 사용하고 있습니다. 장고 1.9는 다음과 같습니다. --run-syncdb선택.입니다.manage.py migrate --run-syncdb내 테이블을 고쳤습니다.

이제(저는 장고 1.9를 사용하고 있습니다) 다음을 만들 수 있습니다.

./manage.py migrate [--database DATABASE] --fake [app_label] [migration_name]

이렇게 하면 문제를 보다 정확하게 파악할 수 있으며 특정 데이터베이스에서 문제가 있는 마이그레이션만 위장할 수 있습니다.

따라서 질문을 살펴보면 다음과 같은 이점이 있습니다.

./manage.py migrate --database default --fake crud crud.0001_initial

비슷한 문제에 직면하여 결국 마이그레이션 폴더의 모든 .py 파일을 삭제하고(django 1.7은 자동으로 하나를 생성함) 그 후 완벽하게 작동했습니다.

저는 칼럼 이름을 바꾼 비슷한 문제들에 직면하고 있었습니다.질문과 함께 제공된 스택 추적에서 언급된 것과 동일한 오류가 발생했습니다.

제가 한 일은 이렇습니다.

가짜 마이그레이션을 먼저 실행했습니다.그런 다음 django_migrations 테이블에서 해당 항목(실행하고 싶은 마이그레이션)을 제거하고 마이그레이션을 다시 실행했습니다(이번에는 거짓 없음).

저에게 예상했던 대로 변화가 나타났습니다.

이것이 도움이 되기를 바랍니다.

장고는 다음을 제공합니다.--fake-initial제가 사용하기에 효과적인 옵션입니다.Django 마이그레이션 설명서에서 다음을(를) 참조하십시오.

-- 가짜 이니셜의 독자

마이그레이션의 모든 CreateModel 작업에 의해 생성된 모든 모델의 이름을 가진 모든 데이터베이스 테이블이 이미 존재하는 경우 Django가 앱의 초기 마이그레이션을 건너뛸 수 있습니다.이 선택사항은 마이그레이션을 사용하기 전에 존재했던 데이터베이스에 대해 마이그레이션을 처음 실행할 때 사용됩니다.그러나 이 선택사항은 일치하는 테이블 이름을 초과하여 일치하는 데이터베이스 스키마를 확인하지 않으므로 기존 스키마가 초기 마이그레이션에 기록된 스키마와 일치하는 경우에만 안전하게 사용할 수 있습니다.

저는 방금 버전 관리에서 프로젝트를 꺼내 몇 가지 새로운 모델 필드를 추가할 준비를 하고 있었습니다.필드를 추가하고, 실행했습니다../manage.py makemigrations그리고 나서 도망을 시도했습니다../manage.py migrate예상대로 많은 필드가 기존 데이터베이스에 이미 존재하기 때문에 오류가 발생했습니다.

내가 했어야 할 일은 도망치는 것이었습니다.makemigrations기존 모델의 상태에 대한 스냅샷을 만들기 위해 프로젝트를 버전 컨트롤에서 꺼낸 직후. 다음 런다그, 을실행을 합니다../manage.py migrate --fake-initial다음 단계가 될 것입니다.

와 런다추수있다니습할가음그▁away▁and▁add다를 추가할 수 .makemigrations>migrate여느 때와 같이

참고: 나는 그것이--fake-initial기존 필드를 건너뛰고 새 필드를 추가합니다.그 시점까지 만든 새 필드에 대해 설명하기로 결정하고,--fake-initial버전 제어에서 꺼낸 후 처음 수행한 작업인 것처럼 다음 마이그레이션에서 업데이트된 필드에 추가했습니다.

기타 관련 설명서: https://docs.djangoproject.com/en/dev/topics/migrations/ #initial-migrations

제 경우에는 마이그레이션 파일이 삭제되고 이름이 다른 새 파일이 자동 생성되었습니다.이름 차이 때문에 Django는 이전에 적용된 마이그레이션 파일과 정확히 동일한 새 마이그레이션 파일을 적용하려고 했습니다. 이 파일은 현재 제거되었습니다.두 가지 모두에서, 새로운 모델이 만들어져야 했고, 그 결과는django.db.utils.ProgrammingError: relation "app_space" already exists마이그레이션을 되돌리려고 했지만 누락된 마이그레이션 파일로 인해 장고가 실제로 되돌리지 못했습니다.학습한 내용은 마이그레이션 파일을 git에 체크인해야 한다는 것입니다.

여기 제가 이 문제의 진상을 규명하는 데 도움이 된 몇 가지 단계가 있습니다. --fake일시적으로 해결되었지만 다음 마이그레이션에서도 동일한 문제가 발생했습니다.추하지않것다입니을천다를 추천하지 않을 것입니다.--fake당신이 그것이 그것에 대한 올바른 사용 사례라는 것을 확실히 알지 않는 한.

이 대답은 저에게 정말 중요했습니다.

1. 전이그레션확python manage.py showmigrations

2. DB Django DB에서 적용된 select * from django_migrations;(사용)psql콘솔에 : postgres DB를 하십시오.psql -h 0.0.0.0 -U <your-db-user>그런 다음 대상 db를 사용합니다.\c <your-db-name>).

3. 더 이상 내 마이그레이션 폴더에 없는 적용된 마이그레이션을 보았습니다.

 20 | app             | 0001_initial                             | 2021-03-05 07:40:20.14602+00
 21 | app             | 0002_some_auto_name                      | 07:40:20.269775+00
 22 | app             | 0003_auto_20210318_2350 <---here         | 2021-03-18 23:50:09.064971+00

에는 그나마레션폴더는에이이가 .0003_auto_20210318_2355동일한 파일이 5분 후에 생성되었습니다.위의 이름으로 마이그레이션 파일의 이름을 변경하여 되돌릴 수 있도록 했습니다.

4. 반환할 마이그레이션을 전달하여 마이그레이션을 되돌립니다.

python manage.py migrate <app-name> <latest-migration-to-which-to-return>

python manage.py migrate app 0002_some_auto_name

5. 여기서 올바른 작업을 수행하고 Git로의 마이그레이션을 확인합니다.그러면 할 수 있습니다.makemigrations그리고.migrate좀 더 평화로운 삶을 살도록 하겠습니다.

저는 이 예외가 발생했을 때 Djangodbshell 유틸리티 또는 MY_DATABASE Viewer / 대화형 명령줄을 사용하여 문제를 해결합니다.

DB Shell:

1. python manage.py dbshell
2. ALTER TABLE [name_of_field_that_already_exists] DROP column [field_table];

저는 몇 년 동안 이 일을 처리해 왔습니다.다른 시나리오가 있을 수 있습니다.

시나리오 1: 원래 게시물에서와 마찬가지로 시작할 테이블이 없습니다.이 경우에는, 저는.

1. 모델의 관계를 설명합니다.파이의
2. python manage를 실행합니다.파이의
3. 이제 성공했다고 가정하고 마이그레이션
4. 당신의 말을 취소합니다.
5. 1단계에서 python manage를 실행합니다.파이 마이그레이션 --가짜

시나리오 2: 여러 앱:한 가지 가능성은 당신이 다른 앱을 가지고 있고 한 앱의 데이터 모델이 다른 앱의 일부 테이블을 사용하고 있다는 것입니다.이 경우 데이터 모델이 올바르게 설계된 경우 setting.py 에서 한 앱에 대한 테이블만 생성한 다음 다른 앱을 추가하고 마이그레이션할 수 있습니다.주의 깊게 설계하지 않고 반복적인 의존성이 있다면 임시 수정보다는 설계 변경을 제안합니다.

시나리오 3: 테이블이 몇 개 있고 마이그레이션에 문제가 발생했습니다. 그러면 저는

1. models.py 을 원래 상태로 되돌리고 models.py 에 이미 존재하는 것으로 보이는 새로운 관계만 소개합니다.
2. 마이그레이션 폴더 삭제
3. python manage를 실행합니다.해적판 이주
4. models.py 에 새로운 변경사항이 있는 경우 이를 소개하고 평소와 같이 마이그레이션 및 마이그레이션 명령을 계속 수행합니다.

키 에서 이 오류의 하고 해결했습니다.member다른 테이블을 가리킵니다.저는 이것을 세 가지 다른 모델로 바꾸다가 모든 모델에서 이 오류를 발견했습니다.내 첫 시도에서 나는 이름을 바꿨습니다.membermember_user그리고 새로운 분야를 만들기 위해 노력했습니다.member새 테이블을 가리키는 외래 키로, 그러나 이것은 작동하지 않았습니다.

제가 발견한 것은 제가 이름을 바꿨을 때member 열식서인이수않정았다니습지하름을덱 .<app>_<model>_<hash>그리고 내가 새로운 것을 만들려고 했을 때member하려고 했습니다. column 해이부시분동이때동기문일인이했생다습니고려성하을.

▁a▁creating▁by▁imember_user관계를 일시적으로 유지하고 데이터를 복사합니다.이렇게 하면 다른 해시를 가진 새 인덱스가 생성됩니다.그런 다음 삭제했습니다.member새 테이블을 가리키고 충돌 가능성이 있는 인덱스 이름을 다시 만들었습니다.일단 그것이 끝나면, 나는 그것을 실행했습니다.RunPython새로운 정보를 입력하는 단계member해당 표에 대한 참조가 있는 열.를 추가하여 마쳤습니다.RemoveField를 member_user열

다음 오류가 발생했기 때문에 마이그레이션을 두 개의 파일로 분할해야 했습니다.

사이코패스2OperationalError: 보류 중인 트리거 이벤트가 있기 때문에 TABLE "<table_name>"을(를) 변경할 수 없습니다.

데이터를 생성하고 복사한 후member_user는 제할수없다를 제거할 수 .member동일한 마이그레이션 트랜잭션에서., 한 후 되었습니다.member_user두 번째 마이그레이션으로.

는 이 를 나는이문발다니에서 했습니다.web2pyframeworkmodels/config.py.

바꾸다

settings.base.migrate = True

구성 파일에서

settings.base.migrate = False

문제는 해결됐습니다.

저는 최근에 같은 문제를 겪었고 여기서 몇 가지 해결책을 시도했습니다. manage.py migrate --fake로 이어졌습니다."django_content_type" does not exist오류. 이전 마이그레이션을 똑같이 삭제하면 마이그레이션이 공유될 경우 다른 사용자에게 문제가 발생할 수 있습니다.

그manage.py squashmigrations명령(명령)이 이 문제를 해결하는 이상적인 방법인 것 같습니다.이전 마이그레이션을 단일 마이그레이션으로 요약하고(이로 인해 순서에 상관없이 적용할 수 없음), 다른 사용자를 위해 이전 마이그레이션을 보존합니다.적어도 제 경우에는 효과가 있었습니다.

저는 가짜와 함께 솔루션을 사용하는 것에 대해 확신할 수 없습니다.대부분 다음 마이그레이션 시 이 오류가 다시 발생합니다.

어떤 열이 해당 문제를 발생시키고 있는지 확인합니다.

1. python manage.py dbshell
2. select * from <tablename> where false;에 의해 할 수 열을 할 수 있습니다
3. alter table <tablename> drop column <columnname>; 프로세스
4. python manage.py makemigrations
5. python manage.py migrate

▁▁you▁error를 실행할 때 이 오류가하는 경우python manage.py test --k테스트 데이터베이스를 삭제하여 수정할 수 있습니다. python manage.py test

저도 같은 문제가 있었습니다. ./manage.py migrate --fake선택사항이 아닙니다. 특히 첫 번째 커밋일 때는 더욱 그렇습니다.을 할 때./manage.py makemigrations마이그레이션 파일을 수집하고 코드에서 모델에 대한 첫 번째 언급인 경우 django는 DB에 이러한 테이블을 생성하려고 시도합니다.치료하려면 다음을 수행해야 합니다.

1. 제다한을 합니다.migrations.CreateModel 파일의
2. 려달을 합니다../manage.py migrate
3. mogrations 파일의 변경 내용을 Ctrl+z

매우 간편한 솔루션

TLDR:

이미 존재하는 오류에 표시되는 마이그레이션 파일의 필드에 주석을 달 수 있습니다.그럼 실행

python manage.파이 이주

마이그레이션이 성공적으로 실행된 후 마이그레이션 파일의 필드에 주석을 달아야 합니다.이제 장고는 데이터베이스에 이미 있는 모든 필드를 건너뛰고 새 필드만 추가합니다.

모델 속성의 이름을 변경했거나 이전에 전체 마이그레이션을 실행하지 않았기 때문일 수 있습니다.

마법의 SQL 기술을 사용하여 테이블을 삭제하거나 테이블이 생성된 경우 이름을 변경하고 마이그레이션을 실행합니다.

전체 마이그레이션 파일이 일관성을 유지하고 새로 생성된 빈 DB에 배포할 수 있는지 확인하십시오.

사용하려고 하지 .--fake데이터베이스가 손상될 위험이 있기 때문입니다.

대신 현재 데이터베이스를 백업하고 재생성한 다음 백업을 적용할 수 있습니다.

1. 생성: 백업만기:pg_dump -F c -v -h localhost <database_name> -f tmp/<pick_a_file_name>.psql

2. rails db:drop db:create

3. : 백업복:pg_restore --exit-on-error --verbose --dbname=<database_name> tmp/<pick_a_file_name>.psql

언급URL : https://stackoverflow.com/questions/29830928/django-db-utils-programmingerror-relation-already-exists