Джанго Юг - таблица уже существует

Я пытаюсь начать с юга. У меня была существующая база данных, и я добавил Юг ( 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

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

./manage.py migrate myapp --fake

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

Хотя таблица «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. Подделка первой миграции:

   ./manage migrate myapp 0001 - поддельный

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

   ./manage перенести myapp

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

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

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

Если у вас есть проблемы с вашими моделями, не соответствующими вашей базе данных, например, @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файле, поэтому в вашей базе данных могут быть таблицы мусора из предыдущих syncdbs или migrates. Чтобы избавиться от них, перед всеми этими миграциями добавьте:

manage.py sqlclear myapp | manage.py sqlshell

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

Perform these steps in order may help you:

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

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

2) python manage.py перенести apps.appname --fake

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

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

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

4) python manage.py перенести apps.appname

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

./manage.py convert_to_south myapp

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

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

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

class Migration(migrations.Migration):

    dependencies = [
        (...)
    ]

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

Или

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

class Migration(migrations.Migration):

    dependencies = [
        (...),
    ]

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

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

$ python manage.py sqlmigrate APP_NAME MIGRATION_NAME

например.,.

$ python manage.py sqlmigrate users 0029_auto_20170310_1117

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