Comment déterminer pourquoi un document MongoDB échoue à la validation?

13

Comment déterminer pourquoi une insertion de document MongoDB échoue à la validation? Tout ce que je reçois est une writeError qui dit "La validation du document a échoué", ce qui n'est pas très utile.

(Cela se produit souvent et j'aimerais comprendre comment les déboguer correctement plutôt que de demander de l'aide avec un exemple spécifique.)

mongodb debugging data-validation

— Jonathan Wheeler
source

10

Comme dans MongoDB 3.2, il n'y a aucun retour sur la raison de l'échec de la validation du document: l'expression de validation globale est actuellement évaluée comme True ("OK") ou False ("Document failed validation"). Le comportement de validation peut être ajusté avec les options de configuration validationAction(erreur / avertir) et validationLevel(stricte / modérée / désactivée), mais cela ne fournit pas de contexte supplémentaire pour les échecs de validation.

Si vous souhaitez obtenir des commentaires plus détaillés, l'approche recommandée serait d'ajouter une logique de validation à votre application plutôt que de vous fier uniquement aux vérifications côté serveur. Même avec la validation côté serveur, de nombreux contrôles sont mieux effectués dans la logique métier de l'application pour minimiser les allers-retours vers le serveur de base de données et fournir des commentaires plus réactifs à l'utilisateur final.

Par exemple, les entrées utilisateur pour une application web (champs obligatoires, formats de champs, ...) doivent être validées dans le navigateur avant d'être soumises à votre application ou de tenter d'insérer / mettre à jour dans la base de données.

Cependant, il est logique de valider à plusieurs niveaux pour garantir la qualité des données et un contexte pour diagnostiquer les échecs de validation serait très utile. Il existe une demande de fonctionnalité ouverte pertinente que vous pouvez regarder / voter dans le suivi des problèmes de MongoDB: SERVER-20547: Exposez la raison pour laquelle une opération échoue à la validation du document .

Pour plus d'informations, vous pouvez également être intéressé par Validation de documents - Partie 1: Ajouter juste la bonne quantité de contrôle sur vos documents . Cela met en évidence certains des avantages et inconvénients généraux de la validation de documents comme dans MongoDB 3.2, et comprend un tableau de référence pour le résultat basé sur validationActionet validationLevelles options de configuration.

— Stennie
source

2

Merci! Je suppose que je ne manquais de rien ici. Nous effectuons en effet la majeure partie de notre validation dans notre application, mais nous laissons des vérifications de bas niveau en tant que validateurs MongoDB, principalement pour nous assurer que nos ingénieurs logiciels (et moi-même) ne créent pas de bogues pendant le développement, plutôt que de trouver des erreurs utilisateur en production. J'ai voté pour la JIRA. À votre santé!

— Jonathan Wheeler

Le problème est que le format du schéma est "semi-standard", c'est-à-dire avec les extensions MongoDB, il est donc difficile de trouver la cause de l'utilisation des validateurs de schéma JSON standard.

— Hendy Irawan

1

@HendyIrawan Oui, il existe quelques extensions du schéma JSON pour les types de données MongoDB, donc une validation ou une transformation client supplémentaire serait requise pour une validation stricte. J'ai vu quelques exemples comme mongo-schemerpour Node.js, qui s'appuie sur AJV (Another JSON Schema Validator) .

— Stennie

1

Bien sûr, la réponse originale est bonne, la gestion de la validation avant d'arriver à la base de données est absolument la meilleure pratique, mais en pratique, si vous devez la poursuivre comme maintenant, vous pouvez temporairement supprimer la validation du schéma et voir ce qui s'affiche dans la Collection.

Si un champ était requis mais qu'il apparaît manquant, vide ou déformé au moins, il restreint votre recherche. Si les données semblent correctes, consultez les validations spécifiées dans le schéma.

— Serexx
source