Strapi использует особый механизм хранения контента, который часто вызывает вопросы у разработчиков: почему у одной и той же сущности может быть несколько записей в базе данных и как на самом деле работают черновики и публикация. Ниже разберём это на уровне концепции и хранения данных.
Ключевая идея: Document ≠ Row
В Strapi документ (document) — это логическая сущность контента, а строки в базе данных — это его версии.
Для одного документа могут существовать две разные записи:
- черновик (draft)
- опубликованная версия (published)
Обе они представляют один и тот же документ, но в разном состоянии.
document_id — то, что связывает версии
В таблице контент-типа Strapi хранит поле document_id.
- Все версии одного документа имеют одинаковый
document_id - Каждая версия — это отдельная строка
- У версии есть собственный
id
Таким образом:
id— конкретная версияdocument_id— логический документ
Как выглядят состояния
У каждой записи есть поле published_at:
published_at = NULL→ черновикpublished_at != NULL→ опубликованная версия
Обычно возможны сценарии:
- Только черновик — документ ещё не публиковался
- Только опубликованная версия — черновик отсутствует
- Две записи — опубликованная версия + новый черновик с правками
Что происходит при создании
- Пользователь создаёт запись
- Strapi создаёт черновик (
published_at = NULL) - Назначается новый
document_id
До публикации существует ровно одна запись.
Что происходит при публикации
Когда пользователь нажимает Publish:
- Strapi копирует данные черновика
- Создаёт новую строку
- Устанавливает
published_at - Обе записи получают одинаковый
document_id
Важно: опубликованная версия — это не обновление черновика, а отдельная запись.
Редактирование опубликованного контента
Если отредактировать уже опубликованный документ:
- опубликованная версия не меняется
- создаётся (или обновляется) черновик
- пользователь работает с черновиком
- публикация снова создаёт новую опубликованную версию
Это даёт:
- стабильность публичных данных
- возможность безопасного редактирования
- предсказуемую историю изменений
Почему так сделано
Такой подход решает сразу несколько задач:
- Чёткое разделение состояний draft / published
- Отсутствие race-condition между редакторами и публичным API
- Возможность расширения (versioning, preview, workflow)
- Простая фильтрация контента для публичного API
Фактически Strapi реализует immutable-подход к публикации.
Как это влияет на запросы
Публичный API
По умолчанию возвращает только записи:
published_at IS NOT NULL
Админка
Работает с документами и версиями:
- группирует по
document_id - выбирает нужную версию в зависимости от контекста
Типичная ошибка разработчиков
Частая проблема — делать JOIN или выборку, не учитывая document_id:
- дубликаты
- «пропавшие» записи
- некорректные связи
Правильный вопрос в Strapi — не «какая строка», а «какая версия документа».
Связи (relations) и документы
Связи в Strapi также привязываются к версиям:
- черновик и публикация могут иметь разные связи
- при публикации связи копируются
Это важно учитывать при миграциях и прямой работе с БД.
Итоговая модель
- Document — логическая сущность
- Version — строка в БД
document_id— ключ группировкиpublished_at— состояние
Понимание этой модели критично, если вы:
- пишете кастомные SQL-запросы
- делаете миграции
- переносите связи
- оптимизируете выборки
Strapi выглядит как обычный CRUD только на поверхности. Под капотом это аккуратно продуманная модель версионирования, которая даёт гибкость, безопасность и масштабируемость контентной архитектуры.
Добавить комментарий