Ошибка Django MySQL при создании таблиц

Ответ 1

Это будет работать

python manage.py migrate auth
python manage.py migrate

Проблема из-за другой миграции выполняется до авторизации, поэтому это приведет к тому, что миграция "authtools" начнется сначала

Ответ 2

Созданы ли миграции для всех ваших приложений? Если нет, вы можете столкнуться с проблемой, что таблицы базы данных создаются в неправильном порядке, что даст вам эту ошибку.

Если у вас есть существующий проект Django 1.7, вам нужно создать начальные файлы миграции, а затем подделать начальную миграцию, как описано здесь.

https://docs.djangoproject.com/en/1.8/topics/migrations/#adding-migrations-to-apps

Создайте перенос с помощью

$ python manage.py make migrations your_app_label

И затем подделать приложение

$  python manage.py migrate --fake-initial your_app_label

Ответ 3

Я встретил эту проблему, пока я использую:

$ python manage.py test

Если вы не выполняли миграцию для тех моделей, у которых есть поле Foreignkey django.contrib.auth.models.User, это приведет к тому, что проблема.

И если вы включили --keepdb, вы обнаружите, что нет таблицы auth_user и другой таблицы администратора django.

Проследим всю проблему:

пробег:

$ python manage.py test --verbosity=3

Вы можете увидеть исключение ограничения foreigngkey, возникшее после

Запуск отложенного SQL...

отложенный sql подобен

"ALTER TABLE xxx ADD CONSTRAINT xx ИНОСТРАННЫЙ КЛЮЧ (x) ССЫЛКИ auth_user"

проверьте исходный код django/core/management/commands/migrate.py:

for statement in deferred_sql:
    cursor.execute(statement)

defered_sql происходит от manifest.items() для цикла,

и manifest происходит от all_models,

и all_models происходит из app_config.label в app_labels.

это аргумент, переданный

self.sync_apps(connection, executor.loader.unmigrated_apps)

Следовательно, executor.loader.unmigrated_apps будет содержать ярлык unmigrated_app, и если у вас есть ключ Foreignkey к Django auth_user, это вызовет ошибку ограничения внешней клавиши в то время, нет таблицы с именем auth_user.

решение:

предположим, что app - это модуль, который содержит классы атрибутов Foreignkey:

$ python manage.py migrate auth
$ python manage.py migrate
$ python manage.py makemigrations app

и если у вас есть другие модули, зависящие от app, предположим, что таблицы базы данных имеют одинаковое поле с модулем app, вам нужно:

$ python manage.py make migrate app --fake

Ответ 4

У меня была та же проблема с внешним ключом author_id.

Решение заключалось в том, чтобы изменить имя из

author = models.ForeignKey(User, related_name='+')

к

writer = models.ForeignKey(User, related_name='+')

попробуйте изменить свое имя поля на нечто иное, чем

group

Ответ 5

Убедитесь, что как внешний ключ, так и первичный ключ имеют тот же тип.

Внешний ключ должен быть того же типа, что и первичный ключ внешней таблицы. У меня был bigint в чужом столе, и django не знал, как автоматически создать внешний ключ, который был автоматически.

Исследуйте, почему миграция завершилась неудачей: python manage.py sqlmraterate {app_name} {mig_name}

Запустите это в рабочем столе, и вы увидите реальную ошибку за неудачей.

django.db.utils.IntegrityError: (1215, "Невозможно добавить ограничение внешнего ключа" )

Ответ 6

У меня была такая же ошибка при попытке настроить CI в BitBucket/Pipelines. Проблема заключалась в том, что я не передал папку миграций в наш репозиторий git, так как Pipelines каждый раз восстанавливает все с нуля, тесты модулей не запускались.

Папка миграции создается при выполнении:

python manage.py makemigrations
python manage.py makemigrations <module_name>

Мои тесты будут работать после выполнения шагов makemigrations/migrate и обеспечения того, чтобы наш не-тестовый код работал.

Кажется, что

python manage.py test 

попытается сгенерировать миграции, если они в настоящее время не существуют, но не всегда может правильно получить зависимости, поэтому вам необходимо убедиться, что вы скопировали автоматически сгенерированный код в папке миграции в исходный код хранилище.

Подробнее о миграции django можно найти здесь: https://docs.djangoproject.com/en/1.11/topics/migrations/

Ответ 7

Если бы та же проблема, оказалось, что каким-то образом Django получил обновление до v1.8, оперативно понизилось до v1.7.

Ответ 8

Я столкнулся с той же проблемой с версией django 1.8. Я решил проблему, выполнив следующие действия: -

При создании таблиц в первый раз: -

python manage.py migrate auth

python manage.py migrate

Это создаст необходимые таблицы для приложений. Затем выполните следующие действия: -

python manage.py migrate --fake-initial app_name

для всех приложений в проекте.

Это создаст первоначальную миграцию для приложений. Теперь, когда вы запускаете тестовый пример, вы не получите никаких ошибок. Просто запустите

Тест python manage.py

и он должен создавать БД и таблицы каждый раз, когда вы запускаете тесты. --keepdb не требуется.

Ответ 9

В Django 1.8 команда syncdb была удалена, вместо syncdb попробуйте выполнить команду manage.py migrate, затем создадут таблицы. после этого вам нужно создать суперпользователя, использующего суперпользователь, или запустить manage.py syncdb, он будет работать.

Ответ 10

Если вышеуказанное не работает и вам не нужен Innodb, то по умолчанию используется MYISAM, поскольку он не имеет такого же уровня ссылочной целостности:

DATABASES = { 
  'default': {
    'ENGINE': 'django.db.backends.mysql',
    'NAME': 'name',                      
    'USER': 'user',     
    'PASSWORD': 'password',
    'OPTIONS': {
           "init_command": "SET storage_engine=MYISAM",
    }   
  }   
}