Кастомные таблицы и xPDO: чек-лист перед продакшеном
Таблица, созданная вручную в базе, ещё не готова к продакшену: обновление может стереть данные, а запрос без индекса — замедлить сайт. Проверьте схему, миграции, ограничения и поведение xPDO до выкладки.
Кастомная таблица в MODX может исправно работать на тестовом сайте и сломаться при первом же обновлении: схема не доедет до сервера, префикс окажется другим, а повторный запуск установщика затрёт данные. Этот чек-лист рассчитан на MODX Revolution 2.8.x с xPDO 2.x; для MODX 3 и другой версии xPDO сверьте детали с документацией именно вашей ветки.
Сначала решите, что именно хранит таблица
Если данные принадлежат конкретному компоненту и не укладываются в штатные объекты MODX, отдельная таблица — нормальный выбор. До проектирования запишите, кто создаёт записи, кто их меняет, как их ищут и что должно происходить при удалении связанного объекта. Последний вопрос часто определяет, останутся ли в базе «осиротевшие» строки.
Определите границы ответственности: схема таблицы, описание модели для xPDO и код компонента должны соответствовать друг другу. Одного SQL-файла, выполненного вручную на рабочем сервере, недостаточно: это изменение, которого не знает процесс развёртывания.
Чек-лист схемы и модели
- Зафиксируйте поля. Для каждого столбца укажите тип, допустимую длину, возможность NULL и значение по умолчанию. Не полагайтесь на неявные настройки MySQL: серверы в разных окружениях могут отличаться.
- Выберите первичный ключ. Убедитесь, что каждая запись однозначно идентифицируется и модель xPDO описывает тот же ключ, что и реальная таблица.
- Опишите связи. Для внешнего ключа решите, что происходит при удалении родительской записи. Если связь поддерживается только логикой приложения, проверьте все пути удаления, включая удаление через менеджер и пакетную обработку.
- Добавьте индексы под реальные запросы. Проверьте поля в условиях фильтрации, соединениях и сортировке. Индекс на каждый столбец не нужен: он занимает место и увеличивает цену записи и обновления.
- Сверьте схему с описанием xPDO. Имена таблиц и полей, типы, ключи и отношения должны совпадать. Если компонент генерирует классы или карту модели, проверьте, что в релиз попадает результат сборки, нужный серверу.
- Проверьте префикс таблиц. Не предполагайте, что он одинаков на локальной машине, тестовом и рабочем сайте. Таблица и модель должны учитывать конфигурацию конкретной установки.
- Проверьте кодировку и сопоставление. Новые таблицы должны согласованно работать с кодировкой базы и столбцов. Иначе поиск и сравнение строк могут вести себя неожиданно.
Миграция1 — это управляемое изменение схемы базы при установке или обновлении компонента. Для каждой версии компонента должно быть понятно, какие изменения применяются и что происходит с уже сохранёнными данными.
Продакшен проверяет не то, умеет ли компонент создать таблицу с нуля, а то, умеет ли он безопасно обновить уже работающую таблицу, не потеряв пользовательские данные.
Выберите способ доставки изменений
Для простого компонента обычно достаточно схемы, которая создаёт отсутствующую таблицу, и отдельной логики обновления существующей. Если схема меняется между версиями, изменения нужно оформлять как последовательные миграции или эквивалентный контролируемый механизм. Ручной SQL оставьте для диагностики или разового восстановления, а не как единственный способ установки.
| Подход | Что выигрываете | Чем платите | Когда выбирать |
|---|---|---|---|
| Ручное создание таблицы | Быстрый старт и полный контроль над разовым изменением | Повторяемость зависит от человека; легко забыть окружение или шаг | Для локального эксперимента, не как процесс релиза |
| Создание схемы при установке | Новая установка получает нужную структуру автоматически | Само по себе не описывает безопасное обновление уже существующей схемы | Для первоначального развёртывания компонента |
| Версионированные миграции | Порядок изменений виден, обновления можно проверять на копии данных | Нужно поддерживать историю и тестировать переходы между версиями | Для компонента, который уже установлен на разных сайтах |
Не запускайте изменение схемы безусловно при каждом запросе страницы. Операция развёртывания должна быть отдельным контролируемым этапом: с журналированием результата и понятным поведением при повторном запуске. Повторный запуск не должен повторно добавлять столбец или очищать таблицу.
Что проверить до выкладки
- Установка на чистой копии. Разверните компонент на базе без его таблиц. Проверьте, что таблица создаётся с ожидаемым префиксом, ключами и индексами.
- Обновление с предыдущей версии. Возьмите копию базы со старыми данными и пройдите весь путь обновления. Убедитесь, что записи сохранились и получили ожидаемую новую структуру.
- Повторный запуск. Запустите этап установки или обновления второй раз. Он должен завершиться предсказуемо, не портить данные и не дублировать изменения.
- Проверка модели через приложение. Создайте, прочитайте, измените и удалите тестовую запись средствами компонента. Сверьте результат с таблицей непосредственно в базе.
- Проверка запросов. На объёме данных, близком к рабочему, проверьте фильтрацию и сортировку. Посмотрите план выполнения запроса и убедитесь, что нужный индекс действительно используется; наличие индекса в схеме этого не гарантирует.
- Проверка сбоя. Разберите, что увидит администратор, если миграция прервётся или у пользователя базы не хватит прав. Должна быть понятная ошибка, а не сайт, который продолжает работать с половиной новой схемы.
Что ломается чаще всего
Описание модели разошлось с таблицей
Приложение ожидает поле или связь, которых нет на сервере, либо получает значение в неожиданном формате. Сравните фактическую схему базы, описание модели и код, который обращается к данным. Проверяйте именно собранный релиз: локальная версия карты модели может отличаться от той, что попала в пакет.
Новая схема прошла только на пустой базе
Создание таблицы не доказывает, что старые данные переживут обновление. Изменение типа, обязательности поля или уникальности может не примениться к существующим строкам. Перед выкладкой проверьте миграцию на копии рабочей базы; если есть неоднозначные данные, сначала определите правило их преобразования.
Запрос замедлился с ростом таблицы
На десятке записей пропущенный индекс незаметен. На рабочем объёме проверяйте самые частые запросы и их план выполнения. Замеряйте время и число прочитанных строк в одинаковых условиях, фиксируя размер таблицы, сервер базы и параметры запроса. Если воспроизводимого замера нет, не обещайте ускорение по одному лишь факту добавления индекса.
Удаление оставило лишние записи
Если приложение не использует ограничение внешнего ключа, удаление родительского объекта может не затронуть связанную строку. Проверьте все сценарии удаления и предусмотрите очистку или архивирование. Не включайте автоматическое каскадное удаление, пока не подтвердили, что оно соответствует правилам хранения данных компонента.
Что делать дальше
Перед релизом сохраните схему и процедуру обновления рядом с исходным кодом компонента, затем прогоните их на копии базы с реальными по структуре данными. Зафиксируйте, сколько занимает миграция, какие права ей нужны и как восстановиться из резервной копии. После выкладки следите за ошибками запросов и временем самых частых операций; инвалидация кеша и проектирование очередей — отдельные темы.
1 Миграция базы — контролируемый переход схемы и, при необходимости, данных от одной версии приложения к другой.
Тендерный специалист 44-ФЗ / 223-ФЗ: Разбор PDF-документации закупки, поиск «заточек» под поставщика, чек-лист заявки.
Спросить за 20 ₽Источники: Документация MODX: xPDO, Документация MODX: создание пакетов и компонентов
Частые вопросы
Можно ли создать кастомную таблицу вручную через phpMyAdmin?
Нужно ли запускать миграцию при каждом открытии сайта?
Что делать, если обновление таблицы завершилось ошибкой?
Как понять, что индекса достаточно?
Подойдут ли эти рекомендации для MODX 3?
Что проверять, если приложение не видит новую таблицу?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.