Как определить, почему документ MongoDB не проходит проверку?

13

Как определить, почему вставка документа MongoDB не проходит проверку? Все, что я получаю, - это writeError с надписью «Проверка документа не пройдена», что не очень полезно.

(Это часто случается, и я хотел бы понять, как правильно их отладить, а не обращаться за помощью к конкретному примеру.)

mongodb debugging data-validation Джонатан Уилер
источник

Ответы:

10

Как и в MongoDB 3.2, обратной связи о причине неудачной проверки документа нет: общее выражение проверки в настоящее время оценивается как True («ОК») или False («Проверка документа не пройдена»). Поведение проверки может быть изменено с помощью параметров конфигурации validationAction(ошибка / предупреждение) и validationLevel(строго / умеренно / выключено), но это не обеспечивает дополнительного контекста для ошибок проверки.

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

Например, пользовательский ввод для веб-приложения (обязательные поля, форматы полей и т. Д.) Должен быть проверен в браузере перед его отправкой в ​​приложение или попыткой вставить / обновить базу данных.

Тем не менее, имеет смысл проводить валидацию на нескольких уровнях, чтобы гарантировать качество данных, и некоторый контекст для диагностики сбоев валидации будет очень полезным. Существует релевантный запрос на открытую функцию, который вы можете просмотреть / проголосовать в системе отслеживания проблем MongoDB: SERVER-20547: Укажите причину, по которой операция не прошла проверку документа .

Для получения дополнительной информации вас также может заинтересовать проверка документов - часть 1: добавление только необходимого количества контроля над вашими документами . Это подчеркивает некоторые общие плюсы и минусы валидации документов, как в MongoDB 3.2, и включает справочную таблицу для результатов, основанных на validationActionи validationLevelопциях конфигурации.

Stennie
источник
2
Спасибо! Думаю, я ничего здесь не пропустил. Мы действительно проводим большую часть нашей проверки в нашем приложении, но мы оставляем низкоуровневые проверки в качестве валидаторов MongoDB, главным образом для того, чтобы убедиться, что наши инженеры-программисты (и я) не создаем ошибки во время разработки, а не находим ошибки пользователя в работе. Я проголосовал за JIRA. Ура!
Джонатан Уилер
Проблема в том, что формат схемы является «полустандарным», то есть с расширениями MongoDB, поэтому все еще трудно определить причину с помощью стандартных валидаторов JSON Schema.
Хенди Ираван
1
@HendyIrawan Да, существует несколько расширений схемы JSON для типов данных MongoDB, поэтому для строгой проверки потребуется дополнительная проверка или преобразование клиента. Я видел несколько примеров, например, mongo-schemerдля Node.js, который основан на AJV (Другой JSON Schema Validator) .
Стенни
1

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

Если поле было обязательным, но оно отображается как пропущенное, пустое или деформированное, по крайней мере это сужает ваш поиск. Если данные выглядят правильно, взгляните на проверки, указанные в схеме.

Serexx
источник