Ужасное название, но именно такое чувство я испытывал последние несколько недель. Подключение здесь, ошибка атрибута там, производственная среда не может понять, что я делал в среде DEV.
Это ворчливое чувство и обращение к stackoverflow для чтения и попытки сопоставить проблему с проблемой, с которой вы сталкиваетесь, но при этом не понимаете, в условиях нехватки времени, могут довести вас до слез. Я был там и надеюсь, что мои слова внесут успокоение в хаос.
Итак, приступим.
Что такое миграции?
Так что же такое миграции. Я не собираюсь давать определения, но для начала представьте это как оператора на вашей свадьбе, который записывает каждого человека, который перекусывает, и проводит виртуальную проверку еды, опасаясь смущения, во время многократных будущих просмотров записи (это индийская вещь ).
Почему тебе должно быть до этого дело?
Что ж, вы не должны, но быть душой, которая определяет, каким будет ваше приложение, не лучше ли осмотреться и узнать, находится ли оно в состоянии безмятежности.
Пример: если вы знаете, какое поле вам нужно использовать, вам не будет проще управлять. Судя по тому, что я видел, мало кто предпочитает CharField вместо использования Boolean или NullBoolean, так что, если появится что-то, кроме истинного или ложного, модель будет отображать данные.
Таким образом приложение будет оптимизировано и станет более понятным для будущих разработчиков, использующих ваш код.
Советы из моего опыта:
Я перейду к сути и дам вам несколько советов по управлению миграциями (попробовал каламбур здесь: D)
Будьте точны при определении миграций. Например, укажите, какой тип поля лучше всего подходит для данных, которые будут обрабатываться вашим приложением. Обратитесь
Очень простой python manage.py makemigrations создаст файл миграции для вашего приложения. Попробуйте открыть папку. ‹App-name› / migrations, и вы найдете там что-то с 0001_initial.py. Предполагается, что это будет ваш первый файл миграции (Ура !!). Рекомендуется использовать -name = ‹имя для файла миграции› при выполнении makemigrations. Это удобный способ отслеживать, что вы сделали и где остановились.
Чтобы узнать, где вы находитесь, попробуйте python manage.py showmigrations, который, в свою очередь, отобразит созданный вами файл миграции [] и из них, которые находятся в синхронизировать с db [X] (вы поймете квадратные скобки, когда запустите эту команду).
Поначалу открытие файла миграции может вызывать ужас, но следите за зависимостями и начальным = True. Они там, чтобы вы знали, на каком контрольном пункте вы стоите. У исходного файла никогда не будет никакой зависимости, но если он что-то делает или кто-то что-то сделал с вашими моделями, и поэтому список зависимостей не пуст.
Если вы застряли в такой ситуации, то сначала попробуйте найти человека и убить неплательщика XD.
Сообщите, что есть много способов справиться с этим.
Перейдите к поиску в базе данных таблицы django_migrations и посмотрите, какие поля присутствуют в соответствии с вашим приложением. Это даст вам представление о том, что происходит.
Итак, что теперь делать. Вы также можете:
- Выполните python manage.py migrate ‹app_name› 0001_intial.py (или укажите точное имя миграции, к которой вы хотите вернуться). Если нет супер-липких миграций, это вернет все к нормальному состоянию и вернет прошлое, которого вы так жаждете.
- Если что-то вышло из-под контроля и все кажется плохим, используйте python manage.py ‹app_name› -zero. Я знаю, что разработчики посоветуют вам этого избежать, но несколько раз меня это успокаивало.
- Не рекомендуется, но если вы хотите использовать стиль пещерного человека, вы можете удалить файл миграции из папки миграции в своем приложении и таблицы django_migration, чтобы избавиться от этой проблемной миграции.
После этого, если приложение все еще аварийно завершает работу, это означает, что база данных и модели не полностью синхронизированы. Вы можете проанализировать это снова, используя python manage.py showmigrations.
Если у вас уже есть все миграции в вашей базе данных, но ваше приложение дает сбой, попробуйте подделать (получить!).
В основном это происходит, когда вы переносите свое приложение с одного сервера на другой или от разработчика к продукту. А если серьезно, вы можете попробовать python manage.py migrate ‹app-name› - -fake. Это заставит django поверить, что вы правильно мигрировали и все в порядке.
Скорее всего, к этому времени у вас будет много миграций. Это не имеет большого значения, но я со временем почувствовал, что лучше хранить все в одном файле. Таким образом, если хоть что-то сломается, вы будете знать, где ломаются ваши миграции и что нужно делать. Вы можете попробовать python manage.py squashmigrations ‹app-name›, чтобы все было в чистоте.
И если ничего не работает python manage.py -help всегда будет рядом, чтобы спасти вас :)
Я надеюсь, что это помогает вам. Буду продолжать обновлять, когда получу больше знаний. И небольшой совет, прочтите документацию :)
Удачного кодирования!
