[БЕЗ_ЗВУКА]
[БЕЗ_ЗВУКА] В этом видео
мы рассмотрим необходимость применения ORM, рассмотрим настройку Django ORM,
описание моделей и их отношения между собой, рассмотрим, что такое миграции,
и также рассмотрим простые запросы: создание, редактирование и удаление.
До этого момента мы не рассматривали хранение данных
пользователя и в дальнейшем выдачу этих данных обратно пользователю.
Это делается с помощью базы данных.
Есть множество способов, как это можно реализовать в коде.
Ну например, один из них — это писать сырой SQL-код.
Это крайне неудобно.
Собственно, первой и основной проблемой является монотонное,
однотипное написание SQL-кода.
Также SQL — это стандарт, но у каждой БД он чуточку свой,
и в случае, если мы захотим как-то поменять базу или что-то в этом роде,
у нас это просто так не получится.
Генерация миграций.
Например, вы добавили какое-то поле, и вам это поле нужно добавить в базу.
И например, вы не один разрабатываете проект, а вас много,
и после того, как вы добавили это поле, вам нужно эту SQL миграцию отправить всем
своим коллегам, они ее тоже применят, и потом, когда ваш код будет раскладываться
на боевой сервер, вам также эту миграцию нужно применить руками.
Крайне неудобно.
На уровне кода сложно понять структуру данных.
То есть везде мы оперируем сырым SQL кодом,
у нас нет где-то централизованной схемы данных.
И вследствие всего этого усложняется реализация бизнес-логики.
Решение.
Все таблицы, которые у нас есть в БД, описываются с помощью Python классов.
Выполнение запросов к БД будем производить через вызов методов данного класса.
Каждая запись в таблице — это объект данного класса.
И на основе изменений наших Python классов мы будем генерировать автоматические
миграции.
Рассмотрим процесс настройки.
Для этого в файлике settings.py есть переменная DATABASES.
Там указываются все базы данных, к которым подключено наше приложение.
Иногда это может быть полезным,
когда у нас есть несколько баз данных, в которых мы пишем.
Для того, чтобы указать дефолтную базу данных,
мы в нашем дикте указываем ключик default и указываем параметры.
Собственно, ENGINE — это тот коннектор,
который будет использоваться для подключения к базе.
NAME — это имя базы, к которой мы будем подключаться.
USER — это имя пользователя, с которым мы будем подключаться к базе.
PASSWORD — это пароль, с которым мы будем подключаться к этой базе.
И, собственно, HOST — это где расположена наша база.
Также есть параметр PORT — на какой порт нужно стучаться.
В этом случае он просто возьмет дефолтный.
И также параметр OPTIONS, он специфичен для каждой базы данных.
Рассмотрим на примере.
Допустим, у нас есть некоторая модель Person.
Мы описываем поле first_name и last_name.
Это нужно делать в файлике models.py.
Собственно, по этой нашей модели будет сгенерирован запрос
в базу данных CREATE TABLE, и там будет указан id, first_name и last_name.
И это нам не приходится делать руками, это все за нас делает автоматически Django.
Теперь давайте рассмотрим поля модели.
Существует множество типов полей: Boolean, Char и т.д.
и т.п, это можно будет посмотреть в материалах для самостоятельного изучения.
И зачем же Django использует эти типы?
Она использует их для определения типа столбца.
То есть мы знаем, что у столбца есть тип в базе данных, например,
INTEGER, VARCHAR или TEXT.
Собственно, на основе этого класса она и определяет тип поля.
Виджет — это HTML виджет, который будет использоваться при отображении,
об этом мы поговорим немного позже.
И минимальные требования к проверке данных, которые переданы в это поле.
Например, есть такой тип поля, как EmailField.
На самом деле это такой же CharField, только в него добавлен валидатор,
который проверяет, что там не просто строка, а именно email.
Рассмотрим отдельно типы полей,
которые помогают организовывать связь между моделями.
Сначала рассмотрим Many2one связь.
Для этого существует тип поля ForeignKey.
Рассмотрим пример.
Допустим, у нас есть модель «производитель» и модель «машина».
У одного производителя может быть множество машин.
Собственно, мы указываем поле «производитель» в модели машины и пишем
там models.ForeignKey, указываем ссылку на производителя и говорим,
что делать в случае удаления производителя.
То есть каскадно удаляем все машины.
Рассмотрим теперь Many2many связь.
Для ее организации также есть свой тип поля, это ManyToManyField.
Собственно, в нем также указываем ссылку на ту модель,
с которой мы хотим организовать Many2many связь.
Теперь рассмотрим параметры полей.
null — если он установлен в True, то Django будет хранить пустые значения,
как NULL в базе данных.
Есть параметр blank.
Если он установлен в True, то поле может быть пустым.
Тонкая грань существует между null и blank.
null — это именно null в базе, а blank — это то,
что Django разрешит принять данные, принять пустые данные.
А в дальнейшем вы можете как-то модифицировать их и, там,
подставить дефолтное значение.
db_index.
В случае, если он установлен в True, то будет построен индекс по этому полю.
default — это, собственно, дефолтное значение этого поля.
primary_key, если он установлен в True,
то это поле будет в дальнейшем считаться первичным ключом.
unique — если он установлен в True, то будет построен уникальный индекс,
и это поле будет уникальным по всей таблице.
И validators — это список валидаторов для этого поля.
Например, вот как мы ранее рассматривали CharField и EmailField,
то вот, собственно, CharField от EmailField отличается именно валидаторами.
Миграции.
Допустим, вы добавили какое-то новое поле в вашу модель.
Вы хотите, чтобы эти изменения отобразились в базе.
Собственно, миграция — это способ применения изменений,
которые делаются в моделях, в схему базы данных.
Это делается с помощью следующих команд.
makemigrations создает файлик миграции.
То есть вы добавили какое-то поле, он определил, какое, и сгенерировал
такой файлик, в котором описаны все действия, которые нужно сделать с базой.
migrate — он берет этот файлик и применяет его к базе.
sqlmigrate — он отобразит тот SQL,
который будет применен во время миграции.
И showmigrations — он отобразит список всех миграций и их статус.
Рассмотрим workflow.
Собственно, вы добавили какое-то поле,
сделали python manage.py makemigrations, он вам сгенерировал файлик.
После этого вы написали python manage.py migrate,
он взял этот файлик и применил его к вашей базе данных.
Например, вы добавили какое-то поле, выполнили этот процесс,
отправили ваш код в GitHub,
ваш коллега получил этот проект и также выполнил migrate,
и у вас базы консистентны: и у вас, и у вашего коллеги.
Теперь рассмотрим простые запросы: создание, редактирование и удаление.
Для этого объявим три модельки.
Это Blog, Author и Entry.
Собственно, для того, чтобы добавить Blog, нужно создать объект
класса Blog и передать в него необходимые кварги, и после этого дернуть save.
Он сгенерирует SQL запросы и выполнит их в базе.
Если же мы хотим изменить какое-то поле, мы меняем это...
мы присваиваем полю какое-то новое значение и дергаем save.
Он определит, что такая запись существует уже в базе и сгенерирует не insert,
а update.
В случае, если мы хотим удалить, мы просто у объекта дергаем delete,
и наша модель удаляется, и, собственно,
строка из базы тоже удаляется.
Теперь рассмотрим сохранение ForeignKey и ManyToManyField.
Например, мы получаем некоторое Entry,
мы хотим поменять в нем Blog.
Собственно, мы получаем Entry,
берем entry.blog, меняем на нужное значение и делаем save.
Собственно, мы поменяли связь.
Для Many2many связи все даже проще.
Если мы хотим Entry соединить с какими-то авторами, мы получаем объекты этих
авторов и делаем entry.authors.add и добавляем этих авторов.
В этом видео мы рассмотрели необходимость применения ORM, ее настройку,
описание моделей и их отношений, миграции,
а также простые запросы: создание, редактирование и удаление.
[ЗВУК]