Django 1.7 migrate получает ошибку "таблица уже существует"

Я пытаюсь применить миграцию, но получаю ошибку:

django.db.utils.OperationalError: (1050, "Таблица" customers_customer ' уже существует ")

Я получаю это, вызывая следующую команду:

python manage.py migrate

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

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

Ответы

Ответ 1

Если у вас есть таблица, созданная в базе данных, вы можете запустить

python manage.py migrate --fake <appname>

Отметить миграции как выполняемые без их фактического запуска

Или, если вы хотите избежать некоторых действий в своей миграции, вы можете отредактировать файл миграции в каталоге приложения/миграции и прокомментировать операции, которые вы не хотите выполнять при выполнении переноса.

Документы: https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south или python manage.py help migrate

Ответ 2

Фактически python manage.py migrate --fake <appname>

Ответ 3

Мы можем решить эту проблему двумя способами, как указано в ответе: 1.) путем редактирования в файле миграции

У нас есть папка миграций, созданная в каждом созданном нами приложении. В этой папке переноса файл миграции (0001_initial.py изначально создан, и после этого будут созданы все другие файлы, зависящие от этого начального файла), Когда мы запустим python manage.py migrate. Для каждого APP файл миграции будет применяться, если есть изменения в файле. Мы можем увидеть этот запуск Применить на терминал после команды migrate. Если в файле миграции есть проблема, мы используем эту ошибку. В моем/нашем случае:

Applying ValetUser.0002_keyroundslots_systemparameters_vehicleparking_vehicleparkingdetails...Traceback (most recent call last):
sqlite3.OperationalError: table "valet_keyroundslots" already exists

Здесь мы можем заметить, что упоминается файл, в котором мы говорим, т.е. ValetUser.0002_keyroundslots_systemparameters. Таким образом, мы можем перейти в приложение, а затем выполнить миграцию и в файле 0002. Мы можем отметить операцию CreateModel этой конкретной модели, в которой мы сталкиваемся с проблемой, пока применяя миграцию. пример:

operations = [
    # migrations.CreateModel(
    #     name='KeyRoundSlots',
    #     fields=[
    #         ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
    #         ('key_round', models.IntegerField()),
    #         ('key_slot', models.IntegerField()),
    #         ('is_available', models.BooleanField()),
    #         ('Valet_id', models.ForeignKey(blank=True, null=True, on_delete=django.db.models.deletion.CASCADE, related_name='valet_location', to='ValetUser.ValetAt')),
    #     ],
    #     options={
    #         'db_table': 'valet_keyroundslots',
    #     },
    # ),

2.) Применяя поддельную миграцию модифицированного файла миграции конкретного APP, в котором мы сталкиваемся с ошибкой/проблемой, --fake применит фальшивую миграцию, которая не повлияет на уже примененную миграцию модели.

python manage.py migrate --fake <appname>

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