Django — PyCharm Не видит команду для миграции БД (manage.py)


Содержание

Создаем свое первое веб-приложение при помощи Django

Django — это Open Source фреймворк для создания веб-приложений различной сложности. Одним из основных преимуществ Django является то, что вам нужно позаботиться только о логике вашего будущего приложения, остальное сделает Django.

Мы создадим веб-приложение, у которого будет панель администратора и возможность загружать загадки, а у пользователей, соответственно, возможность отвечать на них. Во время разработки будут использоваться Python 3.4.3 и Django 1.9.1.

Устанавливаем Django

Делается это очень просто, в командной строке нужно написать: pip install Django==1.9.1 .

Создаем проект

Если вы правильно установили Django, то после запуска django-admin —version вы увидите текущую версию фреймворка. Теперь создадим проект. Это можно сделать следующим образом: django-admin startproject django_example .

Как только создание проекта будет завершено, взглянем на директорию нашего проекта:

  • django_example/__init__.py — пустой файл, который говорит Python, что данная директория должна восприниматься в качестве пакета.
  • django_example/settings.py содержит конфигурацию нашего проекта.
  • django_example/urls.py — здесь объявляются URL.
  • django_example/wsgi.py — с помощью него приложение может работать с веб-сервером по протоколу WSGI.
  • manage.py позволяет взаимодействовать с проектом.

Теперь пришло время запустить наше приложение. Для этого в командной строке нужно написать python manage.py runserver . После этого в адресной строке браузера нужно написать: http://127.0.0.1:8000/ . Если вы увидели «You have unapplied migrations; your app may not work properly until they are applied.», то не волнуйтесь, мы вернемся к этому чуть позже.

Создаем приложение

Определим различие между проектом и приложением. Приложение — это программа, которая что-то делает, а проект — это группа приложений.

Итак, приступим к созданию приложения. Это делается следующим образом: python manage.py startapp riddles .
Как только приложение создано, давайте напишем простой вид, по правилам Django все виды должны храниться в файле views.py .

Теперь, чтобы привязать наш вид к URL, создадим файл urls.py .

В urls.py мы должны написать следующее:

Теперь, если мы запустим наше приложение http://127.0.0.1:8000/riddles/ , мы увидим «Hello, World!».

Установка базы данных

По умолчанию в Django используется SQLite, если она вас не устраивает, то вы можете ознакомиться с нашей статьей, в которой мы рассказываем, как безболезненно перейти с SQLite на MySQL.

4 октября 2020 – 1 марта 2020, Москва и онлайн, беcплатно

Теперь откроем django_example/settings.py и взглянем на переменную INSTALLED_APPS , она хранит все приложения, которые активны в текущем проекте. По умолчанию она содержит:

  • django.contrib.admin — админка, скоро мы ей воспользуемся.
  • django.contrib.auth — система аутентификации.
  • django.contrib.contenttypes — фреймворк для content types.
  • django.contrib.sessions — сессионный фреймворк.
  • django.contrib.messages — фреймворк для отправки сообщений.
  • django.contrib.staticfiles — фреймворк для работы со статичными файлами.

Некоторые из этих приложений используют базы данных, но они еще не установлены, поэтому мы и видели «You have unapplied migrations; your app may not work properly until they are applied.». Поправить это можно следующим образом: python manage.py migrate . Вы должны увидеть следующее:

Теперь создадим нашу модель. Для начала создадим Riddle и Option . В Riddle будет содержаться загадка, в Option — один из возможных ответов на нее.

Данная модель обеспечивает Django информацией, необходимой для создания схемы базы данных и database-access API для доступа к объектам. Теперь нам нужно привязать наше приложение к нашему проекту, делается это следующим образом:

После этого нужно сделать миграцию: python manage.py makemigrations riddles . Вы должны увидеть следующее:

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

Проверить, что сделает миграция, можно так: python manage.py sqlmigrate riddles 0001 (0001 — версия миграции, которую мы хотим проверить). На выходе мы получим:

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

Теперь мы можем начать пользоваться панелью администратора. Но для этого нам нужен пользователь. Создать его можно следующим образом: python manage.py createsuperuser . После этого запускаем сервер, если он не запущен, и переходим на http://127.0.0.1:8000/admin/ . Вы увидите следующее:

Теперь дадим админу возможность изменять наши модели. Делается это так:

Вот что получится в итоге:

Возьмите небольшую паузу и поиграйтесь с панелью администратора. Вы будете приятно удивлены тем, что умеет Django.

Главная страница

Что нам нужно для создания главной страницы?

  • Templates: скелет нашей страницы.
  • Views: функция на Python для отображения контента.

Начнем с шаблонов. Создадим папку templates внутри папки riddle , а в ней создадим index.html .

Теперь создадим макет для ответов:

Здесь мы используем csrf_token , он нужен для защиты от межсайтовой подделки запроса, каждая внутренняя форма должна его использовать. Теперь напишем виды для рендеринга наших шаблонов:

Давайте пройдемся по каждой функции отдельно:

  • index: Index использует функцию render . На вход она получает HttpRequest, местонахождение шаблона и его содержимое, а возвращает HttpResponse с окончательным html.
  • detail: Detail делает практически то же самое, но только функция get_object_or_404 возвращает HttpResponse404, если нужный объект не был найден.
  • answer: Answer ищет предоставленную загадку (и возвращает 404, если она не найдена) и проверяет правильность ответа.

Теперь добавим наши функции в urls.py :

Добавим немного стилей

Для начала создадим директорию static , а в ней создадим файл main.css .

Немного изменим наши шаблоны:

Первая строка загружает статические файлы, потом мы используем <% static '#' %>, где # — путь к вашему файлу. Аналогичная процедура проводится и для JavaScript.


Теперь вы можете создавать свои собственные приложения на Django.

Исходный код нашего приложения можно скачать по этой ссылке.

Python-сообщество

Уведомления

#1 Сен. 13, 2015 01:32:09

[Решено] Не могу произвести migrate — django.db.migrations.graph.CircularDependencyError

Всех приветствую.
Помогите пожалуйста.

Есть 2 аппликухи

Если обе модели сливаю в один файл, migrate проходит на ура. Но я не хочу сливать эти 2 аппликухи в один файл.

тоже все проходит замечательно. Вроде все сделал по букварю.

Благодарю.
________________________________________________________________
РЕШЕНИЕ
1. Комментирую

Отредактировано TitanFighter (Сен. 15, 2015 16:25:41)

#2 Сен. 13, 2015 08:24:20

[Решено] Не могу произвести migrate — django.db.migrations.graph.CircularDependencyError

У вас уже есть M2M связь таблиц Place и ShowTime, вы делаете еще одну связь

#3 Сен. 13, 2015 12:53:04

[Решено] Не могу произвести migrate — django.db.migrations.graph.CircularDependencyError

Добрый день FishHook

Мои странные связи сделаны исходя из документации
+ в данной теме в посте №7 товарищ PooH сказал, что все верно (с поправкой на то, что он подзабыл Джангу).

Я что-то недопонимаю?

Отредактировано TitanFighter (Сен. 13, 2015 12:53:17)

#4 Сен. 13, 2015 18:46:45

[Решено] Не могу произвести migrate — django.db.migrations.graph.CircularDependencyError

#5 Сен. 13, 2015 19:23:25

[Решено] Не могу произвести migrate — django.db.migrations.graph.CircularDependencyError

Логически я понимаю о чем вы говорите, но в документации почему то указано это повторение:

Я ведь делаю по документации за тем исключением, что в документации используются все модели в одном приложении и все работает, а у меня в двух приложениях и эррорит. НО если я все модели переношу в одно приложение (как в документации), все начинает работать, но это 1) меня не устраивает 2) я хочу разобраться в чем дело.

В документации зря усложнили код и можно открывать тикет?

Отредактировано TitanFighter (Сен. 13, 2015 19:26:41)

#6 Сен. 13, 2015 19:41:52

[Решено] Не могу произвести migrate — django.db.migrations.graph.CircularDependencyError

Стоп, я сразу то не увидел, что одна из моделей у вас это through для М2М.
Вышесказанное отменяется.
Вероятно, это ограничение джанговского ОРМа, through модель должна быть описана в том же приложении, где она используется. Вам не надо все модели описывать в одном приложении, а только те которые вы используете в качестве промежуточных для привязки многие-ко-многим (в through).

#7 Сен. 13, 2015 20:52:18

[Решено] Не могу произвести migrate — django.db.migrations.graph.CircularDependencyError

С чем-то подобным сталкивался, навскидку может неточно скажу, но у меня работало и сработало.
Конечно это ограничение джанги, она пробует создавать модели, там ссылка на другую еще несозданную модель, все логично.
Если базы пустые и создаются с нуля, то
1) убрать в одной модели
showtime_place = models.ForeignKey(‘app_places.Place’, verbose_name=’Place’)
2) Сделать makemigrations
3) migrate app_shows_and_times
4) migrate app_places
5) вернуть убранное поле
6) makemigrations и migrate app_shows_and_times

Возможно есть более изящное решение, но в доке джанго примерно такая же рекомендация
Там они еще предлагают потом squashmigrations сделать, чтобы свернуть миграции в одну, я не делал.
Полезно читнуть

А если данные в моделях уже есть, то там надо в сторону fakemigrations смотреть, увы точно не подскажу.

#8 Сен. 14, 2015 05:26:10

[Решено] Не могу произвести migrate — django.db.migrations.graph.CircularDependencyError

А может они просто не в той последовательности импортируются?
Логично было бы, если бы первой импортировалась модель Place, а потом Showtime.
TitanFighter, расставьте принты в классах, как оно у вас происходит?

#9 Сен. 14, 2015 23:01:20

[Решено] Не могу произвести migrate — django.db.migrations.graph.CircularDependencyError

nnmware
1) убрать в одной модели
showtime_place = models.ForeignKey(‘app_places.Place’, verbose_name=’Place’)

вместо предложенной вами строки,
то по итогу просто не создается еще одна таблица (“спаренная”), хотя migrate заканчивается успешно. (Чуть ниже указана последовательность действий в “Путь №1”)

FishHook
TitanFighter, расставьте принты в классах, как оно у вас происходит?

выполняя makemigrations app_shows_and_times или makemigrations app_places

Можно сделать вывод, что при makemigrations сначала идет импортирование моделей, если импортирование проходит успешно, тогда создаются миграции.
Видимо моя проблема не с импортом связана, а с миграцией.

Едит1:
Погуглил еще немного, сопоставив найденное инфо с предложенными шагами от nnmware получил некий незначительный прогресс.

Что попробовал:
Путь №1
1. Комментирую


Едит2:
7. Ок, таблица не создалась. Для эксперимента из п.1 оставляю только movie = models.ManyToManyField(‘app_shows_and_times.Show’) и убираю through=’app_shows_and_times.Showtime’
8. makemigrations app_places -> ok
9. migrate заканчивается ожидаемым

На данный момент мне видится 4 варианта:
1) Понять, почему не создается таблица place_movie из “Путь №1”.
Не имею достаточных знаний, чтобы найти причину самостоятельно. Прошу тут помощи.
Похож ли этот случай на баг? Может постучаться к девам\создать тикет?

В соответствии с Едит2 описанным выше — может и не должно быть никакой отдельной таблицы при использовании параметра through в поле many2many?

2) Заставить как-то Django добавить к полю many2many параметр through, чтоб не возникала ошибка из “Путь №2”.
Гуглил. Предложили создать еще одно поле many2many, добавить в него параметр through, а первое закомментировать. Вообщем, не получится в моем случае — упремся опять в CircularDependencyError

3) Может кто-то еще что-то предложит?

4) Я нагуглил, что с django.db.migrations.graph.CircularDependencyError были проблемы у разных людей в разное время на разных версиях Джанго, и девы фиксили их. Сейчас все работает из коробки в варианте, когда параметр through в many2many ссылается на модель в этом же приложении и нету никакий проблем с миграцией.
По идее, оно должно работать тогда и при ссылке на модель в другом приложении (т.е. без костылей в виде комментирования строки с полем many2many и параметром through + игранием в makemigrations)?
Похож ли этот случай на баг? Может постучаться к девам\создать тикет?

Едит3:
Касательно вопроса заданного в Едит2 по поводу “должна ли вообще создаваться таблица”, пришло озарение, как наверняка можно проверить — взять из документации Джанги код и запустить у себя. При параметре through доп таблица не создается, а используется существующая (которая задается этим самым параметром through, что является логичным, если проследить связи в модели Place “many-2-many+throught” и в модели Showtime, где есть “2 шт ForeignKey”).

Последний вопрос, перед тем как “закрыть” тему:

4) Я нагуглил, что с django.db.migrations.graph.CircularDependencyError были проблемы у разных людей в разное время на разных версиях Джанго, и девы фиксили их. Сейчас все работает из коробки в варианте, когда параметр through в many2many ссылается на модель в этом же приложении и нету никакий проблем с миграцией.
По идее, оно должно работать тогда и при ссылке на модель в другом приложении (т.е. без костылей в виде комментирования строки с полем many2many и параметром through + игранием в makemigrations)?
Похож ли этот случай на баг? Может постучаться к девам\создать тикет?

Отредактировано TitanFighter (Сен. 15, 2015 03:46:04)

Модели

Создание моделей и миграции базы данных

Модели в Django описывают структуру используемых данных. Используемые в программе данные хранятся в базах данных, и с помощью моделей как раз осуществляется взаимодействие с базой данных.

По умолчанию Django в качестве базы данных использует SQLite. Она очень проста в использовании и не требует запущенного сервера. Все файлы базы данных могут легко переноситься с одного компьютера на другой. Однако при необходимости мы можем использовать в Django большинство распространенных СУБД.

Для работы с базами данных в проекте Django в файле settings.py определен параметр DATABASES , который по умолчанию выглядит следующим образом:

Конфигурация используемой базы данных в данном случае складывается из двух параметров. Параметр ENGINE указывает на используемый движок для доступа к БД. В данном случае это встроенный пакет django.db.backends.sqlite3 . Второй параметр — NAME указывает на путь к базе данных. После первого запуска проекта в нем по умолчанию будет создан файл db.sqlite3 , который собственно и будет использоваться в качестве базы данных.

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

pip install psycopg2

pip install mysql-python

pip install cx_Oracle

Создание моделей

При создании приложения по умолчанию в его каталог добавляется файл models.py , который применяется для определения моделей. Модель представляет класс, унаследованный от django.db.models.Model .

Так, изменим файл models.py следующим образом:

Здесь определена простейшая модель, которая называется Person и которая представляет человека. В модели определены два поля. Поле name представляет тип CharField — текстовое поле, которое хранит последовательность символов. Оно будет хранить имя человека. Для CharField обязательно надо указать параметр max_length , который задает максимальную длину хранящейся строки. И поле age представляет тип IntegerField — числовое поле, которое хранит целые числа. Оно предназначено для хранения возраста человека.

Каждая модель сопоставляется с определенной таблицей в базе данных. Однако пока у нас нет в бд таблицы, которая хранит объекты модели Person. И в этом случае нам надо создать и выполнить миграцию. Миграция преобразует базу данных в соответствии с определением моделей.

Вначале необходимо создать миграцию с помощью команды

После этого в приложении в папке migrations мы обнаружим новый файл, который будет иметь примерно следующее содержимое:

Это и есть миграция. Здесь можно заметить, что создается не два, а три поля — поле id, которое будет представлять первичный ключ, добавляется по умолчанию. Поэтому в приниципе в самой модели нам не нужно явным образом определять какой-либо идентификатор.

Теперь надо выполнить данную миграцию. Для этого выполняется команда

После этого, если мы откроем базу данных db.sqlite3 , которая есть в проекте, в какой-нибудь специальной программе для просмотра БД SQLite, то мы увидим, что она содержит ряд таблиц:

Цукерберг рекомендует:  Использование CSS при полном отсутствии HTML в документе

В основном это будут служебные таблицы. А нас прежде всего будет интересовать таблица, которая называется по имени приложения и модели. В моем случае это таблица firstapp_person , которая и будет хранить данные модели Person.

Django Применение изменений в базе данных (Миграции)

пример

После создания новой модели или изменения существующих моделей вам необходимо будет создать миграцию для ваших изменений, а затем применить миграции к указанной базе данных. Это можно сделать, используя встроенную систему миграции Django. Использование утилиты manage.py в корневом каталоге проекта:

Вы можете проверить, какие миграции требуются без фактического создания миграции, используйте параметр -dry-run, например:

Чтобы применить миграции:

Вышеупомянутая команда выполнит сценарии миграции, сгенерированные на первом этапе, и физически обновит базу данных.

Если изменена модель существующей базы данных, для внесения необходимых изменений необходима следующая команда.

Если вы хотите увидеть, какой код SQL будет выполняться с помощью определенной миграции, просто запустите эту команду:

Джанго> 1.10
Новая опция makemigrations —check делает makemigrations —check команды с ненулевым статусом при обнаружении изменений модели без миграции.

См. « Миграции» для получения более подробной информации о миграции.

Documentation

Migrations¶

Migrations are Django’s way of propagating changes you make to your models (adding a field, deleting a model, etc.) into your database schema. They’re designed to be mostly automatic, but you’ll need to know when to make migrations, when to run them, and the common problems you might run into.

The Commands¶

There are several commands which you will use to interact with migrations and Django’s handling of database schema:

  • migrate , which is responsible for applying and unapplying migrations.
  • makemigrations , which is responsible for creating new migrations based on the changes you have made to your models.
  • sqlmigrate , which displays the SQL statements for a migration.
  • showmigrations , which lists a project’s migrations and their status.


You should think of migrations as a version control system for your database schema. makemigrations is responsible for packaging up your model changes into indiv > migrate is responsible for applying those to your database.

The migration files for each app live in a “migrations” directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues’ machines, your staging machines, and eventually your production machines.

Migrations will run the same way on the same dataset and produce consistent results, meaning that what you see in development and staging is, under the same circumstances, exactly what will happen in production.

Django will make migrations for any change to your models or fields — even options that don’t affect the database — as the only way it can reconstruct a field correctly is to have all the changes in the history, and you might need those options in some data migrations later on (for example, if you’ve set custom validators).

Backend Support¶

Migrations are supported on all backends that Django ships with, as well as any third-party backends if they have programmed in support for schema alteration (done via the SchemaEditor class).

However, some databases are more capable than others when it comes to schema migrations; some of the caveats are covered below.

PostgreSQL¶

PostgreSQL is the most capable of all the databases here in terms of schema support.

The only caveat is that prior to PostgreSQL 11, adding columns with default values causes a full rewrite of the table, for a time proportional to its size. For this reason, it’s recommended you always create new columns with null=True , as this way they will be added immediately.

MySQL¶

MySQL lacks support for transactions around schema alteration operations, meaning that if a migration fails to apply you will have to manually unpick the changes in order to try again (it’s impossible to roll back to an earlier point).

In addition, MySQL will fully rewrite tables for almost every schema operation and generally takes a time proportional to the number of rows in the table to add or remove columns. On slower hardware this can be worse than a minute per million rows — adding a few columns to a table with just a few million rows could lock your site up for over ten minutes.

Finally, MySQL has relatively small limits on name lengths for columns, tables and indexes, as well as a limit on the combined size of all columns an index covers. This means that indexes that are possible on other backends will fail to be created under MySQL.

SQLite¶

SQLite has very little built-in schema alteration support, and so Django attempts to emulate it by:

  • Creating a new table with the new schema
  • Copying the data across
  • Dropping the old table
  • Renaming the new table to match the original name

This process generally works well, but it can be slow and occasionally buggy. It is not recommended that you run and migrate SQLite in a production environment unless you are very aware of the risks and its limitations; the support Django ships with is designed to allow developers to use SQLite on their local machines to develop less complex Django projects without the need for a full database.

Workflow¶

Working with migrations is simple. Make changes to your models — say, add a field and remove a model — and then run makemigrations :

Your models will be scanned and compared to the versions currently contained in your migration files, and then a new set of migrations will be written out. Make sure to read the output to see what makemigrations thinks you have changed — it’s not perfect, and for complex changes it might not be detecting what you expect.

Once you have your new migration files, you should apply them to your database to make sure they work as expected:

Once the migration is applied, commit the migration and the models change to your version control system as a single commit — that way, when other developers (or your production servers) check out the code, they’ll get both the changes to your models and the accompanying migration at the same time.

If you want to give the migration(s) a meaningful name instead of a generated one, you can use the makemigrations —name option:

Version control¶

Because migrations are stored in version control, you’ll occasionally come across situations where you and another developer have both committed a migration to the same app at the same time, resulting in two migrations with the same number.

Don’t worry — the numbers are just there for developers’ reference, Django just cares that each migration has a different name. Migrations specify which other migrations they depend on — including earlier migrations in the same app — in the file, so it’s possible to detect when there’s two new migrations for the same app that aren’t ordered.

When this happens, Django will prompt you and give you some options. If it thinks it’s safe enough, it will offer to automatically linearize the two migrations for you. If not, you’ll have to go in and modify the migrations yourself — don’t worry, this isn’t difficult, and is explained more in Migration files below.

Dependencies¶

While migrations are per-app, the tables and relationships implied by your models are too complex to be created for just one app at a time. When you make a migration that requires something else to run — for example, you add a ForeignKey in your books app to your authors app — the resulting migration will contain a dependency on a migration in authors .

This means that when you run the migrations, the authors migration runs first and creates the table the ForeignKey references, and then the migration that makes the ForeignKey column runs afterwards and creates the constraint. If this d > ForeignKey column without the table it’s referencing existing and your database would throw an error.

This dependency behavior affects most migration operations where you restrict to a single app. Restricting to a single app (either in makemigrations or migrate ) is a best-efforts promise, and not a guarantee; any other apps that need to be used to get dependencies correct will be.

Apps without migrations must not have relations ( ForeignKey , ManyToManyField , etc.) to apps with migrations. Sometimes it may work, but it’s not supported.

Migration files¶

Migrations are stored as an on-disk format, referred to here as “migration files”. These files are actually just normal Python files with an agreed-upon object layout, written in a declarative style.

A basic migration file looks like this:

What Django looks for when it loads a migration file (as a Python module) is a sub > django.db.migrations.Migration called Migration . It then inspects this object for four attributes, only two of which are used most of the time:

  • dependencies , a list of migrations this one depends on.
  • operations , a list of Operation classes that define what this migration does.

The operations are the key; they are a set of declarative instructions which tell Django what schema changes need to be made. Django scans them and builds an in-memory representation of all of the schema changes to all apps, and uses this to generate the SQL which makes the schema changes.

That in-memory structure is also used to work out what the differences are between your models and the current state of your migrations; Django runs through all the changes, in order, on an in-memory set of models to come up with the state of your models last time you ran makemigrations . It then uses these models to compare against the ones in your models.py files to work out what you have changed.

You should rarely, if ever, need to edit migration files by hand, but it’s entirely possible to write them manually if you need to. Some of the more complex operations are not autodetectable and are only available via a hand-written migration, so don’t be scared about editing them if you have to.

Custom fields¶

You can’t modify the number of positional arguments in an already migrated custom field without raising a TypeError . The old migration will call the modified __init__ method with the old signature. So if you need a new argument, please create a keyword argument and add something like assert ‘argument_name’ in kwargs in the constructor.

Model managers¶

You can optionally serialize managers into migrations and have them available in RunPython operations. This is done by defining a use_in_migrations attribute on the manager class:

If you are using the from_queryset() function to dynamically generate a manager class, you need to inherit from the generated class to make it importable:

Please refer to the notes about Historical models in migrations to see the implications that come along.


Initial migrations¶

The “initial migrations” for an app are the migrations that create the first version of that app’s tables. Usually an app will have just one initial migration, but in some cases of complex model interdependencies it may have two or more.

Initial migrations are marked with an initial = True > initial class attribute isn’t found, a migration will be considered “initial” if it is the first migration in the app (i.e. if it has no dependencies on any other migration in the same app).

When the migrate —fake-initial option is used, these initial migrations are treated specially. For an initial migration that creates one or more tables ( CreateModel operation), Django checks that all of those tables already exist in the database and fake-applies the migration if so. Similarly, for an initial migration that adds one or more fields ( AddField operation), Django checks that all of the respective columns already exist in the database and fake-applies the migration if so. Without —fake-initial , initial migrations are treated no differently from any other migration.

History consistency¶

As previously discussed, you may need to linearize migrations manually when two development branches are joined. While editing migration dependencies, you can inadvertently create an inconsistent history state where a migration has been applied but some of its dependencies haven’t. This is a strong indication that the dependencies are incorrect, so Django will refuse to run migrations or make new migrations until it’s fixed. When using multiple databases, you can use the allow_migrate() method of database routers to control which databases makemigrations checks for consistent history.

Adding migrations to apps¶

Adding migrations to new apps is straightforward — they come preconfigured to accept migrations, and so just run makemigrations once you’ve made some changes.

If your app already has models and database tables, and doesn’t have migrations yet (for example, you created it against a previous Django version), you’ll need to convert it to use migrations; this is a simple process:

This will make a new initial migration for your app. Now, run python manage.py migrate —fake-initial , and Django will detect that you have an initial migration and that the tables it wants to create already exist, and will mark the migration as already applied. (Without the migrate —fake-initial flag, the command would error out because the tables it wants to create already exist.)

Note that this only works given two things:

  • You have not changed your models since you made their tables. For migrations to work, you must make the initial migration first and then make changes, as Django compares changes against migration files, not the database.
  • You have not manually edited your database — Django won’t be able to detect that your database doesn’t match your models, you’ll just get errors when migrations try to modify those tables.

Reverting migrations¶

Any migration can be reverted with migrate by using the number of previous migrations:

If you want to revert all migrations applied for an app, use the name zero :

Historical models¶

When you run migrations, Django is working from historical versions of your models stored in the migration files. If you write Python code using the RunPython operation, or if you have allow_migrate methods on your database routers, you need to use these historical model versions rather than importing them directly.

If you import models directly rather than using the historical models, your migrations may work initially but will fail in the future when you try to re-run old migrations (commonly, when you set up a new installation and run through all the migrations to set up the database).

This means that historical model problems may not be immediately obvious. If you run into this kind of failure, it’s OK to edit the migration to use the historical models rather than direct imports and commit those changes.

Because it’s impossible to serialize arbitrary Python code, these historical models will not have any custom methods that you have defined. They will, however, have the same fields, relationships, managers (limited to those with use_in_migrations = True ) and Meta options (also versioned, so they may be different from your current ones).

This means that you will NOT have custom save() methods called on objects when you access them in migrations, and you will NOT have any custom constructors or instance methods. Plan appropriately!

In addition, the concrete base classes of the model are stored as pointers, so you must always keep base classes around for as long as there is a migration that contains a reference to them. On the plus side, methods and managers from these base classes inherit normally, so if you absolutely need access to these you can opt to move them into a superclass.

To remove old references, you can squash migrations or, if there aren’t many references, copy them into the migration files.

Considerations when removing model fields¶

Similar to the “references to historical functions” considerations described in the previous section, removing custom model fields from your project or third-party app will cause a problem if they are referenced in old migrations.

Add the system_check_deprecated_details attribute to your model field similar to the following:

After a deprecation period of your choosing (two or three feature releases for fields in Django itself), change the system_check_deprecated_details attribute to system_check_removed_details and update the dictionary similar to:

Цукерберг рекомендует:  Тестирование Django-приложений

You should keep the field’s methods that are required for it to operate in database migrations such as __init__() , deconstruct() , and get_internal_type() . Keep this stub field for as long as any migrations which reference the field exist. For example, after squashing migrations and removing the old ones, you should be able to remove the field completely.

Data Migrations¶

As well as changing the database schema, you can also use migrations to change the data in the database itself, in conjunction with the schema if you want.

Migrations that alter data are usually called “data migrations”; they’re best written as separate migrations, sitting alongside your schema migrations.

Django can’t automatically generate data migrations for you, as it does with schema migrations, but it’s not very hard to write them. Migration files in Django are made up of Operations , and the main operation you use for data migrations is RunPython .

To start, make an empty migration file you can work from (Django will put the file in the right place, suggest a name, and add dependencies for you):

Then, open up the file; it should look something like this:

Now, all you need to do is create a new function and have RunPython use it. RunPython expects a callable as its argument which takes two arguments — the first is an app registry that has the historical versions of all your models loaded into it to match where in your history the migration sits, and the second is a SchemaEditor , which you can use to manually effect database schema changes (but beware, doing this can confuse the migration autodetector!)

Let’s write a simple migration that populates our new name field with the combined values of first_name and last_name (we’ve come to our senses and realized that not everyone has first and last names). All we need to do is use the historical model and iterate over the rows:

Once that’s done, we can just run python manage.py migrate as normal and the data migration will run in place alongside other migrations.

You can pass a second callable to RunPython to run whatever logic you want executed when migrating backwards. If this callable is omitted, migrating backwards will raise an exception.

Accessing models from other apps¶

When writing a RunPython function that uses models from apps other than the one in which the migration is located, the migration’s dependencies attribute should include the latest migration of each app that is involved, otherwise you may get an error similar to: LookupError: No installed app with label ‘myappname’ when you try to retrieve the model in the RunPython function using apps.get_model() .

In the following example, we have a migration in app1 which needs to use models in app2 . We aren’t concerned with the details of move_m1 other than the fact it will need to access models from both apps. Therefore we’ve added a dependency that specifies the last migration of app2 :

More advanced migrations¶

If you’re interested in the more advanced migration operations, or want to be able to write your own, see the migration operations reference and the “how-to” on writing migrations .

Squashing migrations¶

You are encouraged to make migrations freely and not worry about how many you have; the migration code is optimized to deal with hundreds at a time without much slowdown. However, eventually you will want to move back from having several hundred migrations to just a few, and that’s where squashing comes in.

Squashing is the act of reducing an existing set of many migrations down to one (or sometimes a few) migrations which still represent the same changes.

Django does this by taking all of your existing migrations, extracting their Operation s and putting them all in sequence, and then running an optimizer over them to try and reduce the length of the list — for example, it knows that CreateModel and DeleteModel cancel each other out, and it knows that AddField can be rolled into CreateModel .


Once the operation sequence has been reduced as much as possible — the amount possible depends on how closely intertwined your models are and if you have any RunSQL or RunPython operations (which can’t be optimized through unless they are marked as elidable ) — Django will then write it back out into a new set of migration files.

These files are marked to say they replace the previously-squashed migrations, so they can coexist with the old migration files, and Django will intelligently switch between them depending where you are in the history. If you’re still part-way through the set of migrations that you squashed, it will keep using them until it hits the end and then switch to the squashed history, while new installs will just use the new squashed migration and skip all the old ones.

This enables you to squash and not mess up systems currently in production that aren’t fully up-to-date yet. The recommended process is to squash, keeping the old files, commit and release, wait until all systems are upgraded with the new release (or if you’re a third-party project, just ensure your users upgrade releases in order without skipping any), and then remove the old files, commit and do a second release.

The command that backs all this is squashmigrations — just pass it the app label and migration name you want to squash up to, and it’ll get to work:

Use the squashmigrations —squashed-name option if you want to set the name of the squashed migration rather than use an autogenerated one.

Note that model interdependencies in Django can get very complex, and squashing may result in migrations that do not run; either mis-optimized (in which case you can try again with —no-optimize , though you should also report an issue), or with a CircularDependencyError , in which case you can manually resolve it.

To manually resolve a CircularDependencyError , break out one of the ForeignKeys in the circular dependency loop into a separate migration, and move the dependency on the other app with it. If you’re unsure, see how makemigrations deals with the problem when asked to create brand new migrations from your models. In a future release of Django, squashmigrations will be updated to attempt to resolve these errors itself.

Once you’ve squashed your migration, you should then commit it alongs > migrate to store the change in their database.

You must then transition the squashed migration to a normal migration by:

  • Deleting all the migration files it replaces.
  • Updating all migrations that depend on the deleted migrations to depend on the squashed migration instead.
  • Removing the replaces attribute in the Migration >

Once you’ve squashed a migration, you should not then re-squash that squashed migration until you have fully transitioned it to a normal migration.

Serializing values¶

Migrations are just Python files containing the old definitions of your models — thus, to write them, Django must take the current state of your models and serialize them out into a file.

While Django can serialize most things, there are some things that we just can’t serialize out into a val > repr() only works for basic values, and doesn’t specify import paths).

Django can serialize the following:

  • int , float , bool , str , bytes , None , NoneType
  • list , set , tuple , dict , range .
  • datetime.date , datetime.time , and datetime.datetime instances (include those that are timezone-aware)
  • decimal.Decimal instances
  • enum.Enum instances
  • uuid.UUID instances
  • functools.partial() and functools.partialmethod instances which have serializable func , args , and keywords values.
  • LazyObject instances which wrap a serializable value.
  • Any Django field
  • Any function or method reference (e.g. datetime.datetime.today ) (must be in module’s top-level scope)
  • Unbound methods used from within the > deconstruct() method ( see below )

Serialization support for functools.partialmethod was added.

Serialization support for NoneType was added.

Джанго 1.7 — makemigrations не обнаружение изменений

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

Приложение было первоначально под 1.6, поэтому я понимаю , что миграция не будет там изначально, и в самом деле , если я бегу python manage.py migrate я получаю:

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

Но если я бегу python manage.py makemigrations myapp я получаю:

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

Есть ли способ заставить приложение на миграцию и по существу сказать «Это моя базу для работы с» или что-нибудь? Или я что-то отсутствует?

Моя база данных PostgreSQL является один, если это помогает вообще.

Если вы переход от существующего приложения вы сделали в Джанго 1.6, то вам необходимо сделать один предварительный шаг (как я выяснил), перечисленный в документации:

питон manage.py makemigrations your_app_label

Документация не делает это очевидным , что вам нужно добавить ярлык приложения к команде, как и первое , что он говорит вам , чтобы сделать это , python manage.py makemigrations который потерпит неудачу. Начальная миграция выполняется при создании приложения в версии 1.7, но если вы пришли с 1,6 она не была бы проведена. Смотрите «Добавление миграции к приложениям» в документации для получения более подробной информации.

Хорошо, похоже, что я пропустил очевидный шаг, но размещение этого в случае, если кто-то делает то же самое.

При обновлении до 1.7, мои модели стали неуправляемыми ( managed = False ) — я их , как и True раньше , но , кажется , он получил вернулся.

Удаление этой строки (чтобы по умолчанию True) , а затем работает makemigrations сразу сделал модуль миграции , и теперь он работает. makemigrations не будет работать на неуправляемых таблиц (очевидно, задним числом)

Мое решение не было покрыто здесь , так что я отправляю его. Я использовал syncdb для проекта-только , чтобы получить его и работает. Затем , когда я пытался начать использовать Django миграции, он подделал их сначала тогда бы сказать , что это «ОК» , но ничего не происходит с базой данных.

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

Тогда я только что сделал первоначальные миграции с:

./manage.py makemigrations my_app

./manage.py migrate my_app

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

Согласен с @furins. Если кажется, что все в порядке, и все же эта проблема возникает, контроль, если есть какой-либо метод свойства с таким же названием, как атрибут, который вы пытаетесь добавить в классе модели.

  1. Удалить метод с похожим именем атрибута вы добавляете.
  2. manage.py makemigrations my_app
  3. manage.py мигрировать my_app
  4. Добавьте методы обратно.

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

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

Хотя, возможно, это поможет кому-то :-)

Это может произойти из-за следующие причины:

  1. Вы не добавили приложение в INSTALLED_APPS списке в settings.py (Вы должны добавить как имя приложения или пунктирный путь к подклассу AppConfig в apps.py в папке приложения, в зависимости от версии Джанго вы используете). См документации: INSTALLED_APPS
  2. У вас нет migrations папки внутри этих приложений. (Решение: просто создать эту папку).
  3. Вы не имеете __init__.py файл в migrations папку этих приложений. (Решение: Просто создайте пустой файл с именем __init__.py )
  4. Вы не имеете __init__.py файл в папке приложения. (Решение: Просто создайте пустой файл с именем __init__.py )
  5. Вы не имеете models.py файл в приложении
  6. Ваш класс Python (должен быть моделью) в models.py не наследуется django.db.models.Model
  7. У вас есть некоторая семантическая ошибка в определении моделей в models.py

Примечание: Общая ошибкой является добавление migrations папки в .gitignore файле. Когда клонированы из удаленного репозитория, migrations папки и / или __init__.py файлы будут отсутствовать в местной репо. Это вызывает проблемы.


Я предлагаю игнорировать файлы миграции, добавив следующие строки в .gitignore файл

Ответ на этот StackOverflow почтой, cdvv7788 Миграции в Django 1.7

Если это первый раз, когда вы переносите это приложение, которое вы должны использовать:

manage.py makemigrations myappname После того, как вы делаете, что вы можете сделать:

manage.py мигрировать Если у вас приложение в базе данных, модифицировали модель и ее не обновляя изменения на makemigrations вы, вероятно, мигрировали нету еще. Изменить модель вернуться к своей первоначальной форме, запустить первую команду (с именем приложения) и перенести . это будет подделать. После того, как вы сделаете это положил обратно изменения на вашей модели, запустите makemigrations и мигрируют снова и он должен работать.

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

Я переехал мое Джанго приложение cloud9 и по какой-то причине я никогда не ловил начальную миграцию.

Django 1.7 — makemigrations не обнаруживает изменений

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

Приложение изначально было под 1.6, поэтому я понимаю, что миграций там не будет изначально, и действительно, если я запущу python manage.py migrate I получим:

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

Но если я запускаю python manage.py makemigrations myapp , я получаю:

Похоже, что не имеет значения, что или как я запускаю команду, оно никогда не определяет приложение как имеющее изменения и не добавляет никаких файлов миграции в приложение.

Есть ли способ принудительно перенести приложение на миграцию и, по сути, сказать: «Это моя база для работы» или что-нибудь в этом роде? Или я что-то упустил?

Моя база данных — это PostgreSQL, если это вообще помогает.

23 ответа

Хорошо, похоже, что я пропустил очевидный шаг, но публикую его на тот случай, если кто-то другой сделает то же самое.

При обновлении до 1.7 мои модели стали неуправляемыми ( managed = False ) — у меня они были как True и раньше, но, похоже, все изменилось.

Удаление этой строки (по умолчанию True) и последующий запуск makemigrations немедленно сделали модуль миграции, и теперь он работает. makemigrations не будет работать с неуправляемыми таблицами (что очевидно задним числом)

Если вы переходите с существующего приложения, созданного в django 1.6, вам нужно сделать один предварительный шаг (как я выяснил), указанный в документации:

python manage.py makemigrations your_app_label

Документация не указывает на то, что вам нужно добавить метку приложения в команду, так как первое, что она скажет вам сделать, это python manage.py makemigrations , который потерпит неудачу. Первоначальная миграция выполняется, когда вы создаете свое приложение в версии 1.7, но если вы перешли с версии 1.6, это не будет выполнено. См. «Добавление миграции в приложения» в документации для получения дополнительной информации. подробности.

Это может произойти по следующим причинам:

  1. Вы не добавили приложение в список INSTALLED_APPS в settings.py (Вы должны добавить либо имя приложения , либо пунктирный путь к подклассу AppConfig в файле apps.py в папке приложения, в зависимости от используемой версии django). См. Документацию: INSTALLED_APPS
  2. В этих приложениях нет папки migrations . (Решение: просто создайте эту папку).
  3. У вас нет __init__.py внутри migrations папка этих приложений. (Решение: просто создайте пустой файл с именем __ init __. Py )
  4. В папке приложения нет файла __init__.py . (Решение: просто создайте пустой файл с именем __ init __. Py )
  5. У вас нет models.py в приложении
  6. Ваш класс Python (который должен быть моделью) в models.py не наследует django.db.models.Model
  7. У вас есть некоторая семантическая ошибка в определении моделей в models.py

Примечание: Распространенной ошибкой является добавление папки migrations в .gitignore файл. При клонировании из удаленного репозитория папка migrations и /или __init__.py файлы будут отсутствовать в локальном репо. Это вызывает проблемы.

Я предлагаю игнорировать файлы миграции, добавив следующие строки в .gitignore file

Мое решение здесь не освещалось, поэтому я публикую его. Я использовал syncdb для проекта — просто чтобы запустить его. Затем, когда я попытался начать использовать миграцию Django, он сначала подделал их, затем сказал, что все в порядке, но с базой данных ничего не происходило.

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

Затем я только что выполнил начальную миграцию с помощью:

./manage.py makemigrations my_app

./manage.py migrate my_app

Теперь я могу выполнять миграции без проблем.

Согласитесь с @furins. Если кажется, что все в порядке, и все же эта проблема возникает, проверьте, существует ли какой-либо метод свойства с таким же названием, что и у атрибута, который вы пытаетесь добавить в класс Model.

  1. Удалите метод с именем, аналогичным добавляемому атрибуту.
  2. manage.py makemigrations my_app
  3. manage.py migrate my_app
  4. Добавьте методы обратно.

Это довольно глупая ошибка, но лишняя запятая в конце строки объявления поля в классе модели делает эту строку бесполезной.

Это происходит, когда вы копируете вставку def. от миграции, которая сама определяется как массив.

Хотя, может быть, это кому-нибудь поможет: -)

Ответ в этом сообщении stackoverflow от cdvv7788 Миграции в Django 1.7

Если вы мигрируете это приложение в первый раз, вы должны использовать:

manage.py makemigrations myappname После того, как вы это сделаете, вы можете сделать:

manage.py migrate Если ваше приложение было в базе данных, изменили его модель и это не обновляет изменения на makemigrations, вы, вероятно, не перенесли это еще. Измените свою модель на первоначальную, запустите Первая команда (с именем приложения) и мигрировать . это будет имитировать. однажды Вы делаете это, чтобы вернуть изменения в вашу модель, запустить makemigrations и мигрировать снова, и это должно работать.

У меня были точно такие же проблемы, и все вышеперечисленное сработало отлично.

Я переместил свое приложение django в cloud9 и по какой-то причине я никогда не улавливал начальную миграцию.

Возможно, я опоздал, но вы пытались добавить в приложение папку migrations с __init__.py файл в нем?

Может быть, это кому-нибудь поможет. Я использовал вложенное приложение. project.appname и у меня фактически были project и project.appname в INSTALLED_APPS. Удаление проекта из INSTALLED_APPS позволило обнаружить изменения.

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


  1. Удалите изменения, которые вы хотите синхронизировать.
  2. Запустите python manage.py makemigrations app_label для начальной миграции.
  3. Запустите python manage.py migrate для создания таблиц перед внесением изменений.
  4. Вставьте изменения, которые вы удаляете на первом этапе.
  5. Выполните шаги 2. и 3.

Если вы перепутали какой-либо из этих шагов, прочитайте файлы миграции. Измените их, чтобы исправить вашу схему или удалить ненужные файлы, но не забудьте изменить часть зависимостей следующего файла миграции;)

Я надеюсь, что это поможет кому-то в будущем.

Следующее сработало для меня:

  1. Добавьте имя приложения в settings.py
  2. используйте ‘python manage.py makemigrations’
  3. используйте ‘python manage.py migrate’

У меня сработало: Python 3.4, Django 1.10

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

Запуск makemigrations в папке проекта означает, что он будет искать все таблицы, относящиеся ко всем приложениям, включенным в settings.py для проекта. Как только вы включите его, makemigrations автоматически включит приложение (это сэкономит много работы, поэтому вам не придется запускать makemigrations app_name для каждого приложения в вашем проекте /сайте).

На тот случай, если у вас есть конкретное поле, которое не идентифицируется при помощи makemigrations: дважды проверьте, есть ли у вас свойство с тем же именем.

свойство «перезапишет» определение поля, поэтому изменения не будут идентифицироваться как makemigrations

Добавление этого ответа, потому что только этот метод помог мне.

Я удалил папку migrations и запустил makemigrations и migrate .
В нем все еще сказано: Нет миграций для применения.

Я пошел в папку migrate и открыл последний созданный файл,
прокомментируйте миграцию, которую я хотел (она была обнаружена и введена там)
и снова запустите migrate .

Это в основном редактирует файл миграции вручную.
Делайте это, только если вы понимаете содержание файла.

Убедитесь, что ваша модель не abstract . Я действительно допустил эту ошибку, и это заняло некоторое время, поэтому я решил опубликовать ее.

Использовали ли вы schemamigration my_app —initial после переименования старой папки миграции? Попытайся. Может работать. Если нет — попробуйте воссоздать базу данных и сделайте syncdb + migrate. Это сработало для меня .

У меня была та же проблема с тем, что мне приходилось дважды запускать makemigrations и все виды странного поведения. Выяснилось, что корень проблемы заключался в том, что я использовал функцию для установки дат по умолчанию в своих моделях, поэтому при миграции выполнялись изменения при каждом запуске make-миграций. Ответ на этот вопрос поставил меня на правильный путь: Избегайте искусственных мигрантов воссоздать поле даты

Недавно я обновил Django с 1.6 до 1.8, и у меня было мало приложений и миграций для них. Я использовал south и schemamigrations для создания миграций в Django 1.6, который отсутствует в Django 1.8.

Когда я добавил новые модели после обновления, команда makemigrations не обнаружила никаких изменений. И затем я попробовал решение, предложенное @drojf (1-й ответ), оно работало нормально, но не смогло применить поддельную начальную миграцию ( python manage.py —fake-initial ) , Я делал это, так как мои таблицы (старые таблицы) уже были созданы.

Наконец, это сработало для меня, удалили новые модели (или изменения модели) из models.py, а затем пришлось удалить (или переименовать для безопасного резервного копирования) папку миграций всех приложений и запустить python manage.py сделал миграцию для всех приложений, затем сделал python manage.py migrate —fake-initial . Это работает как шарм. После того как начальная миграция создана для всех приложений, а поддельная начальная миграция добавлена, добавлены новые модели, после чего выполняется обычный процесс makemigrations и выполняется миграция в этом приложении. Изменения были обнаружены сейчас, и все прошло хорошо.

Я просто подумал поделиться им здесь, если кто-то сталкивается с той же проблемой (имея schemamigrations юга для своих приложений), это может помочь их:)

Может быть, это может кому-то помочь, у меня была такая же проблема.

Я уже создал две таблицы с классом сериализатора и представлениями. Поэтому, когда я хотел обновить, у меня была эта ошибка.

Я выполнил следующие действия:

  1. Я сделал .\manage.py makemigrations app
  2. Я выполнил .\manage.py migrate
  3. Я удалил обе таблицы из моего models.py
  4. Я удалил все ссылки на свои таблицы из сериализатора и класса представления.
  5. Я выполнил шаг 1 и 2 .
  6. Я получил свои изменения только в models.py
  7. Я снова выполнил шаг 5 .
  8. Я восстановил все свои изменения.

Если вы работаете с Pycharm, местная история очень полезна.

Может быть, это кому-нибудь поможет.

Я удалил свой models.py и ожидал makemigrations для создания DeleteModel операторов.

Не забудьте удалить файлы *.pyc !

Миграции отслеживают изменения в БД, поэтому, если вы переходите с неуправляемой на управляемую, вам необходимо убедиться, что таблица базы данных обновлена ​​и соответствует модели, с которой вы работаете.

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

ПОМНИТЕ: если у вас есть переход, который заканчивается на _001 в вашей IDE & _003 в вашей базе данных. Django увидит, есть ли у вас миграция, заканчивающаяся на _004, для обновления чего-либо.

2 (миграция кода и базы данных) связаны и работают в тандеме.

Добавил этот ответ, потому что у меня не работало ни одно из перечисленных выше.

В моем случае происходило что-то еще более странное ( Django 1.7 Version ), в моем models.py у меня было «extra» . строка в конце моего файла (это была пустая строка), и когда я выполнил команду python manage.py makemigrations , результат был: » изменений не обнаружено «.

Чтобы это исправить, я удалил «пустую строку» , который был в конце моего файла models.py , и снова запустил команду, все было исправлено и все изменения, внесенные в models.py , были обнаружены!

Добавление моего 2c, поскольку ни одно из этих решений не помогло мне, но это сработало .

Я только что запустил manage.py squashmigrations и удалил старые миграции (как файлы, так и строки в таблице базы данных django.migrations).

Это оставило такую ​​строку в последнем файле миграции:

South — django db migration. Изменение структуры базы данных Django

Django — один из самых популярных фреймворков для python. Он поддерживает автоматическое создание баз данных для ваших приложений. Достаточно выполнить

и в указанной вами базе данных будут созданы все таблицы, соответствующие определенным в models.py классам моделей.

У встроенной syncdb есть один недостаток — он не умеет менять структуру базы данных при изменении модели.

На практике это означает, что при добавлении пары элементов данных в описание вашей модели вам нужно будет вручную менять структуру таблиц в БД, либо создавать базу данных заново, теряя все данные.

На помощь приходит такой инструмент, как South.

Как работает Django South


Изменение базы с помощью south происходит в два этапа

  • South определяет, что нужно изменить и создает файл-миграцию
  • Миграция применяется к базе данных, отражая изменения моделей

Как это выглядит на практике

Сперва нужно создать начальную миграцию:

Это сохранит для дальнейшей работы south начальную схему базы данных.

Для создания таблиц в базе для приложения с имеющимися миграциями, после установки south недостаточно выполнить syncdb — нужно выполнить сами миграции:

При изменении модели нужно выполнить те же действия, только скрипты для миграции создаются с параметром —auto вместо —initial

То есть когда вы изменили вашу модель, выполните:

Установка Django South

Для установки вам нужно выполнить

и добавить south в INSTALLED_APPS settings.py вашего Django приложения.

После этого нужно выполнить

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

Внесение изменений в модель без удаления базы данных

Если в вашей базе данных уже есть информация, то перед изменением модели нужно сообщить south начальную структуру базы.

Допустим, мы хотим изменить модель Page в приложении pages, и при этом не хотим вносить уже записанные в базу данные заново.

Для этого выполните следующие команды:

Первая команда создаст в каталоге приложения директорию migrations, в котором будет создан файл 0001_initial.py, описывающий создание текущей структуры.

При выполнении команды migrate, south применяет к базе все миграции, начиная с последней выполненной. Но в данном случае в базе уже есть нужные таблицы, поэтому первая миграция не сможет выполнится без ошибок.

Поэтому вторая команда запускается с ключом —fake — это даст south знать, что миграцию нужно отметить как выполненную, на самом деле не меняя базы.

Теперь внесите в модель нужные изменения. Допустим, мы добавили с помощью modeltranslation переводы полей title, seo_description и content на русский и украинский языки. При этом в базе должны быть созданы поля для хранения информации на указанных языках.

После этого выполните команду:

В команде schemamigration изменилось два параметра: вместо —initial мы указали —auto — это означает, что south попытается автоматически определить, что изменилось с момента последней миграции, и создать вторую миграцию, которая будет добавлять нужные поля в базу. Также я указал название для миграции: add_pages_translation.

Создание пользовательских команд управления в Django

Django распространяется с различными утилитами (командами), выполняемыми в командной строке, которые вызываются с помощью скрипта django-admin.py или manage.py (Custom Django Management Commands). Хорошая вещь в том, что вы также можете добавить свои собственные команды. Они могут хорошо помочь, когда необходимо взаимодействовать с приложением из командной строки терминала, а также их можно использовать в cron — утилите, использующейся для периодического выполнения заданий в определённое время.

Вступление

Перед тем, как начнем писать свои команды, ознакомимся с интерфейсом команднйо строки Django. Как минимум, при начале разработки в Django, вы должны были ознакомиться с такими командами, как startproject , runserver и collectstatic . Полный перечень встроенных команд можно узнать из справки:

Результат будет примерно таким:

Свои команды создаются в приложениях: создается каталог management, с вложенным каталогом commands. Пример:

В качестве названия команды, вызываемой в команднйо строке используется имя файла. В нашем примере файл my_custom_command.py , так что команда будет вызываться следующим образом:

Основной пример

Создадим базовый пример своей команды:

management/commands/what_time_is_it.py

В основном команда управления Django состоит из класса с именем Command , который наследуется от BaseCommand . Код команды должен быть определен внутри метода handle() .

Посмотрите, мы назвали наш модуль what_time_is_it.py . Эта команда может быть выполнена как:

Вывод исполнения команды:

Возникает вопрос, чем это отличается от обычного скрипта Python или в чем его польза. Наилучшим преимуществом является то, что все возможности Django доступны и готовы к использованию, что можно импортировать модели, выполнять запросы в базу данных с помощью ORM Django и взаимодействовать со всеми ресурсами проекта.

Обработка аргументов

Для обработки аргументов команды Django использует argparse, которая является частью стандартной библиотеки Python. В своей команде мы должны использовать метод add_arguments .

Позиционные аргументы

Следующий пример — это команда, создающая случайных пользователей. Она принимает обязательный аргумент total , который определяет, сколько пользователей должно быть создано этой командой.

management/commands/create_users.py

Использование этой команды:

Опциональные аргументы

Опциональные (и именованные) аргументы могут передаваться в любом порядке. В следующем примере находится определение аргумента prefix , который будет скомпонован с полем username .

management/commands/create_users.py

Если указан префикс, то поле username будет, например, таким: custom_user_oYwoxtt4vNHR . Без указания префикса результат будет следующим: oYwoxtt4vNHR , т. е. просто случайная строка.


Флаговые аргументы

Один из типов необязательных аргументов — это флаг, который использует булевый тип. Давайте добавим флаг — admin , для указания команде создать суперпользователя или обычного пользователя, если флаг не указан.

management/commands/create_users.py

Произвольный список аргументов

Давайте создадим новую команду delete_users . В ней мы передадим список идентификаторов пользователей, которых команда должна удалить из базы данных.

management/commands/delete_users.py

Также мы можем передать список id , разделенных пробелом, таким образом команда удалит пользователей за один вызов:

Стилизация

Можно улучшить предыдущий пример, добавив цвета для вывода сообщений:

management/commands/delete_users.py

Ниже предоставлен список всех доступных стилей в виде пользовательской команды:

Задания для утилиты cron

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

Этот пример будет выполнять каждый день в 4 часа команду my_custom_command .

Представления-классы
(Class-Based Views)

Детальное описание и структура классов Django.

Django DetailView — основы использования

Django позволяет создавать приложения очень легко. Если приложение должно быть выпущено быстро и является относительно общим, то эта среда Python идеально подходит для этого. В течение нескольких лет я профессионально работал в этой среде и часто рылся внутри, поэтому знаю почти всё, и сегодня я представлю вам все, что нужно знать, чтобы эффективно использовать универсальный DetailView в Django.

Выпущены исправления Django: 2.2.7, 2.1.14 и 1.11.26

Сегодня команда разработчиков Django выпустила версии 2.2.7, 2.1.14 и 1.11.26 с исправлениями ошибок. Пакет и контрольные суммы доступны на странице загрузок, а также из индекса пакетов Python. Идентификатор ключа PGP, использованный в этом выпуске: Mariusz Felisiak: 2EF56372BA48CD1B.

Как заставить request.is_ajax() работать с JS fetch()

Объект запроса Django request имеет изящный небольшой метод is_ajax(). Он позволяет определить, поступил ли запрос от JS-фреймворка (он же ajax старой школы). Хотя он отлично работает с некоторыми библиотеками JS, включая почтенный jQuery, он не будет работать с современным встроенным в JS fetch().

Практика программирования на Python 3, лекция №5

Лекции о Python 3 от Тимофея Хирьянова при поддержке Московского физико-технического института. Лекция №5.

Практика программирования на Python 3, лекция №4

Лекции о Python 3 от Тимофея Хирьянова при поддержке Московского физико-технического института. Лекция №4.

Практика программирования на Python 3, лекция №3

Лекции о Python 3 от Тимофея Хирьянова при поддержке Московского физико-технического института. Лекция №3.

Практика программирования на Python 3, лекция №2

Лекции о Python 3 от Тимофея Хирьянова при поддержке Московского физико-технического института. Лекция №2.

Практика программирования на Python 3, лекция №1

Лекции о Python 3 от Тимофея Хирьянова при поддержке Московского физико-технического института. Лекция №1.

Как загрузить файлы с Django

В этом руководстве вы узнаете о принципах загрузки файлов Django и о том, как обрабатывать загрузку файлов с использованием форм моделей. В конце этого поста вы найдете исходный код примеров, которые я использовал, чтобы вы могли попробовать и изучить.

Советы по написанию миграции данных в приложении Django

В приложении Django при изменении схемы Django автоматически создает файл миграции для изменений схемы. Мы можем написать дополнительные миграции для изменения данных. В этой статье мы узнаем несколько советов по написанию миграций данных в приложениях Django.

Django — PyCharm Не видит команду для миграции БД (manage.py)

Опубликовано: 2 года назад

В этой статье осуществлена попытка собрать полезности, по работе с популярным web-фреймворком на Python.

Поводом к ее написанию стало прочтение серии из семи замечательных статей, написанных Vitor Freitas в блоге simpleisbetterthancomplex.com. По мере прочтения стало понятно, что вся информация в голове не уляжется и нужно складывать ее в более для того подходящее хранилище.

Команды django-admin и manage.py

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

Операции с моделями

Шаблоны тестов

Проверка HTTP-кода ответа для адреса с alias-ом home.

Проверка, что URL вызывает правильную view

Шаблоны регулярных выражений для URL

В этом разделе приведены несколько примеров наиболее часто используемых шаблонов для файла urls.py.

Автогенерируемый первичный ключ

Цукерберг рекомендует:  Белые хакеры
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих