У меня есть веб-проект, работающий с приличным количеством данных в MySQL db. Я пытаюсь обновить базу данных с некоторыми изменениями в приложении под названием «enterlink». Я создал новые элементы в существующих моделях и создал новые модели. Перед этой миграцией я никогда не касался схемы db с момента запуска исполняемого файла syncdb для его создания. Когда я запускаю: «python manage.py makemigrations enterlink» появляется нижний вывод (рис.). Мой вопрос: почему это происходит? БД уже включает в себя все модели, которые он перечисляет на картинке, так зачем регистрировать эти списки моделей? Когда я иду, чтобы закончить миграцию, выполнив «python manage.py migrate» или «python manage.py migrate --fake enterlink» (снова pic), я получаю вывод, но моя схема базы данных остается идентичной старой db и любой новый код генерирует ошибки. Может ли кто-нибудь сказать мне, что может быть проблемой? Я был бы очень благодарен за любые советы. Это было очень неприятно, так как я не уверен, что мне не хватает.Невозможно получить Django 1.7 Миграции для обнаружения правильных изменений в моей БД.

What the output looks like when I makemigrations my enterlink app

2015-01-21 EazyC

Что вы сделали, так это то, что вы выполнили команду python manage.py syncdb перед запуском python manage.py makemigrations myapp и python manage.py migrate myapp. Вот почему syncdb создал схему базы данных, и миграция была подделана, потому что схема уже существует. Я предлагаю использовать python manage.py makemigrations myapp и python manage.py migrate myapp и не использовать syncdb как устаревший в Django 1.7.

Если вы что-то изменили в своей модели, просто запустите команду makemigrations и migrate. Syncdb не требуется.

источник

2015-01-21 08:01:59 ruddra

Спасибо за ваш ответ. Я только сделал syncdb для самого первого создания db приложения. Теперь, когда я не могу начать заново, потому что у меня уже есть большой объем данных в моих рядах, что я могу сделать? Я попытался выполнить makemigrations myapp и перенести myapp, как вы предлагаете, но ни одна из этих двух команд в настоящее время не создает новые таблицы, которые мне нужны. Предполагаете ли вы, что мне нужно выполнить некоторую домашнюю работу в своей БД, прежде чем попытаться обновить файл models.py и начать процесс миграции? – EazyC

Если бы я был вами, я бы сначала создал резервную копию текущей базы данных (dumpdata), затем создал новую базу данных, запустил «makemigrations» и «migrate», а затем импортировал дампдаты в новую базу данных. @SwAvGuy. Создание нового db обязательно не означает сброс базы данных, просто создайте новый с другим именем и проверьте, работает ли он для вас, а затем сделайте то, что вы считаете наиболее подходящим. :) – ruddra

Я попробую и обновлю, если это сработает. Спасибо за ваши предложения. Но просто любопытно, правильно ли я понимаю вас, что проблема возникает из-за того, что Django не создал начальную схему миграции для моей первой конфигурации базы данных, потому что я использовал syncdb? Возможно, это источник ошибок? – EazyC

Im новичок для schemamigration тоже, но я объясню, как это работает для меня:

Первого вы создаете приложение, а затем ./manage.py sycndb, поэтому таблицы создаются тогда вы можете ./manage.py makemigrations MyApp --initial так что теперь начальные миграции создаются, и вы должны их применять ./manage.py мигрировать MYAPP теперь вы можете изменить свои модели: а дд, поля изменения, все, что вы хотите, и затем ./manage.py makemigrations MyApp --auto это создаст миграции для изменения и теперь вы должны применять их enter code here ./manage.py мигрируют MyApp так что это на самом деле будет создавать новые таблицы в db

источник

2015-01-21 07:52:47

Спасибо за ответ. Поэтому, если я правильно понимаю вас, вы говорите, прежде чем обновлять файл models.py с новым файлом models.py с изменениями в моей модели и БД, мне нужно сначала makemigrations -myapp -initial, прежде чем я это сделаю что-нибудь еще? После этого, только тогда я должен переключить файл models.py и попытаться изменить структуру БД? – EazyC

прежде всего резервные файлы/база данных –

затем ./manage.py makemigrations myapp --initial then ./manage.py migrate myapp затем вносить изменения ./manage.py makemigrations myapp --auto и применять ./manage.py migrate myapp –

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

Испытано в django1.5.5

Инициализация базы данных:

./manage.py syncdb --noinput
./manage.py migrate
./manage.py syncdb

Теперь я создал базу данных.

Выполнение миграции для приложения:

./manage.py schemamigration myapp --initial
./manage.py migrate myapp --fake
Теперь сделайте необходимые изменения в модели
./manage.py schemamigration myapp --auto
./manage.py migrate myapp

источник

2015-06-06 21:19:48

Привет, спасибо! С тех пор я хорошо это понял для своей сборки, но это очень полезный пост с кем-то с похожими проблемами, когда я ищу ответы. – EazyC

Невозможно получить Django 1.7 Миграции для обнаружения правильных изменений в моей БД.

ответ

Инициализация базы данных:

Выполнение миграции для приложения:

Смежные вопросы