Валидация схемы и уникальные индексы

Валидатор — обычный BSON-документ с оператором $jsonSchema внутри, а внутри него — подмножество стандарта JSON Schema с BSON-привкусом. Ключ bsonType описывает тип: object для корня документа, string для строк, int и long для целых, double и decimal для дробей, date для дат, objectId для идентификаторов — это BSON-типы, а не строки JSON, и int здесь значит int32 на проводе. Список required называет обязательные поля, словарь properties описывает схему каждого поля: для возраста — bsonType int с минимумом и максимумом, для email — строка с pattern, регулярным выражением, которому строка обязана соответствовать, для статуса — enum с набором допустимых значений. Важное свойство: валидатор — это предикат запроса, наравне с $gt и $exists, поэтому внутри легален любой оператор запроса, а сам $jsonSchema работает не только в описании коллекции, но и в find и в этапе $match конвейера — этим мы воспользуемся для аудита чуть ниже. Вариантов завода два: при создании коллекции — CreateCollection с опциями, для существующей — collMod через RunCommand. Уровни строгости и действия при нарушении настраиваются отдельными опциями, и о них следующий раздел.

Параметр validationLevel отвечает за то, кого проверяют. strict — все вставки и все обновления без исключений, значение по умолчанию. moderate — вставки проверяются все, а обновления — только тех документов, которые уже удовлетворяют схеме: документ, родившийся до введения валидатора и не прошедший бы проверку, можно обновлять по полям, не входящим в конфликт с новым контрактом. Это спасает коллекции с легаси-данными: strict на живой коллекции с нарушителями способен заблокировать рядовые обновления, потому что сервер перепроверяет документ целиком, а не только изменённые поля. off выключает проверку совсем — опция для временного отключения без удаления валидатора. Параметр validationAction отвечает за реакцию: error отклоняет нарушителя ошибкой — это дефолт и правильный выбор для новых коллекций; warn пишет предупреждение в журнал сервера, но документ сохраняет. Режим warn полезен на одном этапе: перед включением строгого контракта погоняйте день-другой в warn и посчитайте предупреждения — это честная статистика того, сколько документов strict отрезал бы. Полагаться на warn постоянно не стоит: без мониторинга журнала он превращается в декорацию, и данные тихо плывут дальше. Оба параметра — обычные строки в SetValidationLevel и SetValidationAction, и при смене через collMod они передаются ключами validationLevel и validationAction.

CreateCollection создаёт коллекцию с валидатором, но только новую: повторный вызов на существующем имени упадёт с ошибкой NamespaceExists, а «перезаписать» контракт он не умеет. Живую коллекцию меняют командой collMod через db.RunCommand: документ команды с ключами collMod, validator и, при желании, validationLevel и validationAction. Здесь стоит нюанс драйвера v2: RunCommand принимает только упорядоченный документ — bson.D, и карта bson.M для команды не годится, что прямо сказано в документации метода. Возвращается *SingleResult: метод Err отдаёт статус команды, Decode при желании разберёт ответ сервера. Текущий контракт читается обратно: ListCollectionSpecifications возвращает спецификации с полем Options типа bson.Raw, из которого Lookup по ключу validator достаёт действующий документ — удобно проверять тестом, что контракт на месте после миграции. Тот же collMod в mongosh — db.runCommand({collMod: ...}) — ведёт себя одинаково: контракты не завязаны на язык клиента, поэтому править их можно любым инструментом, а поведение сверять между mongosh и Go.

На нарушение валидатора сервер отвечает кодом 121 — у него есть имя DocumentValidationFailure, но в Go код сравнивается числом. У одиночных вставок и обновлений это WriteException со срезом WriteErrors, у InsertMany и BulkWrite — BulkWriteException; правила те же, что выучены в двадцатом уроке про duplicate key: пачка unordered продолжает вставку и собирает все нарушения, ordered останавливается на первой. Проверка кода — метод HasErrorCode(121) интерфейса mongo.ServerError, который достаётся errors.As через любую цепочку обёрток; альтернатива — руками вскрыть WriteErrors и сравнить поле Code, но HasErrorCode короче и покрывает оба типа исключений. Самое ценное лежит в поле Details у WriteError: сервер кладёт туда errInfo — документ с идентификатором нарушителя и деревом несработавших правил схемы, по которому видно и поле, и причину. Драйвер errInfo не парсит — читайте bson.Raw через Lookup, когда нужно отдать пользователю внятную причину, а не общий 400. Отдельно держите в голове warn-режим: там ошибки не будет вовсе, только строки в журнале сервера, и нарушения ищутся не в коде, а в логах. В общей карте ошибок 121 — сосед кода 11000: дубликат говорит «такой ключ уже занят», валидация — «документ не той формы», и оба превращаются в доменные ошибки на границе репозитория.

Поскольку $jsonSchema — обычный оператор запроса, им можно искать документы, которые схеме соответствуют. Инверсия — $nor с $jsonSchema внутри — выбирает всё, что контракту не удовлетворяет: db.users.find с таким предикатом вернёт ровно нарушителей. Это дешёвый аудит перед ужесточением: сначала collMod в warn-режиме, затем посчитать и разглядеть нарушителей запросом, затем включить strict, когда счётчик уйдёт в ноль. Тот же приём находит и обратное — документы, которые контракту соответствуют, если предикат применить без инверсии; для быстрой оценки объёма достаточно countDocuments вместо полной выборки. В конвейере агрегации предикат живёт в этапе $match, поэтому отчёт по нарушителям с группировкой по полям собирается тем же инструментом, что и любой другой отчёт. Аудит-запросы выполняйте на вторичном узле с read preference secondary, если коллекция большая: скан по всей коллекции для отчёта не должен мешать записи. И помните про explain из урока про индексы: $jsonSchema в фильтре не опирается на индексы и честно сканирует — для разового аудита это нормально, для панельного запроса — нет.