Создание проекта, первые модели и админ-панель

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

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

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

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

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

Параметр ENGINE указывает на применяемый для доступа к БД движок. В нашем случае это встроенный пакет django.db.backends.sqliteЗ.
Параметр NАМЕ указывает на имя и путь к базе данных. После первого запуска проекта в нем по умолчанию будет создан файл db.sqliteЗ, который, собственно, и будет служить в качестве базы данных.

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

Создание модели базы данных

Наша первая задача - создать модель базы данных, в которой мы сможем хранить и отображать сообщения наших пользователей.

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

Откройте файл posts/models.py и посмотрите на код по умолчанию, который предоставляет Django:

from django.db import models

# Create your models here

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

Мы хотим создать модель для хранения текстового содержимого сообщения на доске объявлений, что можно сделать следующим образом:

from django.db import models


class Post(models.Model):
    text = models.TextField()

Обратите внимание, что мы создали новую модель базы данных под названием Post, которая имеет поле базы данных text. Мы также указали тип содержимого, которое оно будет хранить, TextField(). Более подробно про модели мы поговорим в следующем разделе.

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

Миграции моделей

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

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

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

Убедитесь, что локальный сервер остановлен, нажав комбинацию клавиш Ctrl+C в командной строке, а затем выполните команды:

python manage.py makemigrations posts

python manage.py migrate

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

Если вы просто запустите python manage.py makemigrations, будет создан файл миграций для всех доступных изменений в проекте Django.

Это хорошо для небольшого проекта, такого как наш, с единственным приложением, но большинство Django проектов имеют более одного приложения!

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

Поэтому в качестве лучшей практики возьмите за правило всегда указывать имя приложения при выполнении команды makemigrations!

Как можно видеть, после выполнения команды makemigrations создан файл с миграцией posts/migrations/0001_initial.py и получено сообщение: Create model Post (создана модель Post).

Новый файл 0001_initial.py, расположенный в папке migrations нашего приложения posts, будет иметь примерно такое содержимое:

# Generated by Django 5.0.0 on 2024-02-11 16:27

from django.db import migrations, models


class Migration(migrations.Migration):

    initial = True

    dependencies = [
    ]

    operations = [
        migrations.CreateModel(
            name='Post',
            fields=[
                ('id', models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
                ('text', models.TextField()),
            ],
        ),
    ]

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

После ввода команды makemigrations было создано только описание полей для таблицы Post, в которой будут храниться данные в поле text, при этом сама таблица в БД еще не была создана.

А уже после ввода команды migrate на основе описания полей в модели данных создается соответствующая таблица в БД.

Мы можем посмотреть нашу таблицу через SQLiteStudio, или если мы работаем в PyCharm Professional то можем легко посмотреть содержимое нашей таблицы:

В основном это служебные таблицы. Но нас интересует наша таблица Posts, в которой будут храниться данные.

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

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