Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Практически любое веб-приложение так или иначе работает с базой данных. При этом с системой управления базами данных (СУБД) приложение общается универсальным способом, например, посредством языка SQL.

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

3 <h2>ORM</h2>

4 ORM (Object-Relational Mapping)- отображение сущностей предметной области и их взаимосвязей в объекты, удобные для использования программистом.

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

6 Другие ORM только оборачивают сущности базы данных в структуры языка, но все запросы нужно писать вручную. Это два разных полюса, каждый со своими плюсами и минусами. Авторы Django решили остаться где-то посередине.

7 Если использовать Django ORM, можно работать с объектами и выполнять вручную их загрузку и сохранение. Однако для этого можно использовать привычные средства языка: итерацию, вызов методов.

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

9 <h2>Модель</h2>

10 Любая сущность, которая создается внутри приложения, называетсямоделью. Модели в Django лежат в директориях приложений в файлахmodels.py. Конкретный набор моделей зависит от приложения и может измениться со временем. На Хекслете таких моделей сотни, вот лишь некоторые, с которыми наши пользователи сталкиваются каждый день:

11 <ul><li>Пользователь</li>

12 <li>Курс</li>

13 <li>Урок</li>

14 <li>Профессия</li>

15 <li>Упражнение</li>

16 <li>Подписка</li>

17 <li>Участник курса</li>

18 <li>Статья в блоге</li>

19 <li>Топик</li>

20 <li>Комментарий к топику</li>

21 <li>Проект</li>

22 </ul>Важно не путать понятие модель во фреймворке, с понятием модель в MVC. Последнее - это не про класс, файл, функцию или структуру данных. Это слой приложения, который отвечает за модель предметной области. И это не про базу данных.

23 Слово "модель" часто используется в качестве замены словосочетания "Django ORM", поэтому в рамках курсов будет использоваться этот термин. Модель в единственном числе говорит нам о том, что наша предметная область смоделирована с помощью средств фреймворка. Это собирательный образ слоя хранения. При этом отдельные сущности тоже называются моделями - модели поменьше собираются в большую модель всей предметной области.

24 Связь между моделями и таблицами в базе данных: одна таблица - одна модель. В этом плане Django ORM не отходит далеко от схемы базы данных. Всегда можно представить, как фактически представлены данные с точки зрения СУБД. Что очень полезно, когда нужно что-то оптимизировать.

25 <h2>Database Engines</h2>

26 К фактической базе данных Django подключается с помощьюDatabase Engines. Одно приложение может подключаться к нескольким базам данных. Это можно сделать и с помощью разных движков. Но такое случается нечасто. Обычно одна база приходится на одно веб-приложение.

27 Описываются базы данных в словаре settings.DATABASES:

28 <ul><li>ENGINE указывает на конкретный движок</li>

29 <li>NAME в случае SQLite хранит имя файла. Для других СУБД это будет имя базы данных в удобном для них формате</li>

30 <li>default - имя базы данных уже для самого Django</li>

31 </ul>Когда используется несколько баз данных одновременно и имя другой не указано в коде явно, эта "база данных по умолчанию" используется всегда.

32 <h2>Описание моделей</h2>

33 Модели описываются в модуляхmodels.py. Каждое приложение имеет свой собственный модульmodels.py, в котором содержатся описание моделей конкретного приложения.

34 Добавим в hexlet_django_blog.article.models следующий код:

35 Article - это и есть наша первая модель. У нее четыре поля:

36 <ul><li>created_at - для хранения даты и времени создания записи</li>

37 <li>updated_at - для хранения даты и времени последнего изменения записи</li>

38 <li>name- для хранения названия статьи</li>

39 <li>body - для хранения текста статьи</li>

40 </ul>В этом случае мы не описываем поле id, которое обычно является первичным ключом. Вmodels.Modelоно уже описано, и нам не нужно это делать дополнительно. Но мы его можем переопределить.

41 Со стороны Python всё готово. Но еще нужно сделать так, чтобы соответствующая таблица появилась в базе данных. Для этого необходимо сгенерировать миграцию.

42 <h2>Миграция</h2>

43 Миграции меняют схему базы данных сообразно тому, как мы меняем модель. В Django работа с миграциями сделана на очень высоком уровне. В том числе - на высоком уровне автоматизации.

44 Чтобы получить миграцию, выполняем команду:

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

46 Миграции- это описания изменений в наших моделях, и в дальнейшем в схеме базы данных. Мы можем просмотреть эти файлы миграций. Они располагаются в директорияхmigrationsвнутри приложений. Например, в нашем случае файл миграции располагается вhexlet_django_blog/article/migrations/0001_initial.py.

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

48 Теперь посмотрим, какой SQL-запрос будет выполняться при запуске миграции. Для этого воспользуемся командой sqlmigrate:

49 <ul><li>Имена таблиц автоматически генерируются с помощью объединения имени приложения (article) и имени модели в нижнем регистре - article</li>

50 <li>Поле id, которое является первичным ключом, добавляется автоматически</li>

51 </ul>Применяем все остальные миграции. Эта операцияидемпотентна:

52 Созданная миграция была применена. Если все прошло успешно, то в базе данных появилась таблицаarticle_article.

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

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

55 Например, в директорииmigrationsприложенияarticleу нас есть два файла миграции0005_second_last_migrationи0006_last_migration. 0006 - это последняя примененная миграция.

56 Если нам нужно вернуться к миграции 0005 из миграции 0006, мы выполним следующую команду:

57 Если нам нужно отменить все миграции этого приложения, нужно указать zero в качестве версии миграции:

58 Иногда миграция может быть необратимой. Как правило, это возникает, когда в модели вносятся существенные изменения. Когда мы попытаемся вернуться к такой миграции, Django выдаст ошибку IrreversibleError.