Джанго Юг - таблица уже существует - PullRequest
188 голосов
/ 22 июня 2010

Я пытаюсь начать с юга. У меня была существующая база данных, и я добавил Юг (syncdb, schemamigration --initial).

Затем я обновил models.py, чтобы добавить поле, и запустил ./manage.py schemamigration myapp --auto. Казалось, он нашел поле и сказал, что могу применить это с ./manage.py migrate myapp. Но это дало ошибку:

django.db.utils.DatabaseError: table "myapp_tablename" already exists

tablename - первая таблица, указанная в models.py.

Я использую Django 1.2, Юг 0.7

Ответы [ 8 ]

311 голосов
/ 22 июня 2010

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

./manage.py migrate myapp --fake

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

41 голосов
/ 24 октября 2011

Хотя таблица "myapp_tablename" уже существует, ошибка прекращается после того, как я это сделал ./manage.py переносим myapp --fake, ошибка DatabaseError не показывает такого столбца: myapp_mymodel.added_field.

У меня точно такая же проблема!

1. Сначала проверьте номер миграции , который вызывает это.Предположим, что это: 0010.

2. Вам нужно:

./manage.py schemamigration myapp --add-field MyModel.added_field
./manage.py migrate myapp

, если отсутствует более одного поля, вам нужно повторить его для каждого поля.

3. Теперь вы попадаете с кучей новых миграций, поэтому удалите их файлы из myapp / migrations (0011 и далее, если вам нужно добавить несколько полей).

4. Запустите это:

./manage.py migrate myapp 0010

Теперь попробуйте ./manage.py перенести myapp

Если не получится, вы готовы.Просто дважды проверьте, если какие-либо поля не пропущены.

РЕДАКТИРОВАТЬ:

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

  1. Подделка первой миграции:

    . / Управление миграцией myapp 0001 --fake

  2. Сверните с остальными миграциями:

    . / Управление миграцией myapp

10 голосов
/ 30 марта 2012

Когда я столкнулся с этой ошибкой, у нее была другая причина.

В моем случае Саут как-то оставил в моей БД временную пустую таблицу, которая используется в _remake_table () . Возможно, я прервал миграцию так, как не должен был делать. В любом случае, каждая последующая новая миграция, когда она вызывала _remake_table (), выдавала ошибку sqlite3.pypysqlite2.dbapi2.OperationalError: table "_south_new_myapp_mymodel" already exists, потому что действительно уже существует и ее не должно быть.

Бит _south_new показался мне странным, поэтому я просмотрел свою БД, увидел таблицу _south_new_myapp_mymodel, почесал голову, посмотрел на источник Юга , решил, что это мусор, уронил стол и все было хорошо.

2 голосов
/ 30 июля 2014

Если у вас есть проблемы с вашими моделями, не соответствующими вашей базе данных, например, @pielgrzym, и вы хотите автоматически перенастроить базу данных в соответствии с последним файлом models.py (и стереть все данные, которые не будут воссозданы приборами во время migrate):

manage.py schemamigration myapp --initial
manage.py migrate myapp --fake
manage.py migrate myapp zero
manage.py migrate myapp

Это приведет к удалению и воссозданию только тех таблиц базы данных, которые существуют в вашем последнем файле models.py, поэтому в вашей базе данных могут быть таблицы мусора из предыдущих syncdb s или migrates.Чтобы избавиться от них, перед всеми этими миграциями добавьте:

manage.py sqlclear myapp | manage.py sqlshell

И если из-за этого в вашей базе данных останется CRUFT, вам нужно будет сделать inspectdb и создать models.pyфайл из этого файла (для таблиц и приложения, которое вы хотите очистить) перед выполнением sqlclear, а затем восстановите исходный файл models.py перед созданием миграции --initial и переходом на него.Все это, чтобы не возиться с особенностями SQL, которые нужны вашей базе данных.

2 голосов
/ 23 октября 2013

Perform these steps in order may help you:

1) python manage.py schemamigration apps.appname --initial

Вышеописанный шаг создает папку миграции по умолчанию.

2) python manage.py migrate apps.appname --fake

создает поддельную миграцию.

3) python manage.py schemamigration apps.appname --auto

Затем вы можете добавить поляпо вашему желанию и выполните приведенную выше команду.

4) python manage.py migrate apps.appname

1 голос
/ 22 июля 2014

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

./manage.py convert_to_south myapp

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

Команда convert_to_south полностью работает только на первой машине, на которой вы ее запускаете. После того, как вы завершили начальную миграцию, которую он осуществил в VCS, вам придется запускать ./manage.py migrate myapp 0001 --fake на каждом компьютере, на котором есть копия кодовой базы (сначала убедитесь, что они были в курсе моделей и схемы). ref: http://south.readthedocs.org/en/latest/convertinganapp.html

0 голосов
/ 05 апреля 2017

Еще одно решение (возможно, временное решение).

$ python manage.py sqlmigrate APP_NAME MIGRATION_NAME

например,.

$ python manage.py sqlmigrate users 0029_auto_20170310_1117

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

0 голосов
/ 05 апреля 2017

В качестве временного решения вы можете прокомментировать создание таблицы в скрипте миграции.

class Migration(migrations.Migration):

    dependencies = [
        (...)
    ]

    operations = [
        #migrations.CreateModel(
        #    name='TABLE',
        #    fields=[
        #            ....
        #            ....
        #    ],
        #),
        ....
        ....

или

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

class Migration(migrations.Migration):

    dependencies = [
        (...),
    ]

    operations = [
        migrations.RunSQL("DROP TABLE myapp_tablename;")
    ]
...