web-dev-qa-db-ja.com

MongoDBドキュメントが検証に失敗した理由を特定するにはどうすればよいですか?

MongoDBドキュメントの挿入が検証に失敗した理由を確認するにはどうすればよいですか?返されるのは、「ドキュメントの検証に失敗しました」というwriteErrorだけです。これはあまり役に立ちません。

(これは頻繁に発生します。特定の例について助けを求めるのではなく、これらを適切にデバッグする方法を理解したいと思います。)

13

MongoDB 3.2と同様に、ドキュメントの検証が失敗した理由に関するフィードバックはありません。現在、検証式全体はTrue( "OK")またはFalse( "Document failed validation")として評価されています。検証動作はvalidationAction(エラー/警告)およびvalidationLevel(厳密/中程度/オフ)構成オプションで調整できますが、これは検証エラーのコンテキストを提供しません。

より詳細なフィードバックが必要な場合は、サーバー側のチェックだけに頼るのではなく、アプリケーションに検証ロジックを追加することをお勧めします。サーバー側の検証を行う場合でも、データベースサーバーへのラウンドトリップを最小限に抑え、エンドユーザーに応答性の高いフィードバックを提供するために、多くのチェックはアプリケーションビジネスロジックで行うのが最適です。

たとえば、Webアプリのユーザー入力(必須フィールド、フィールド形式など)は、アプリケーションに送信する前、またはデータベースに挿入/更新する前に、ブラウザーで検証する必要があります。

ただし、データの品質を保証するために複数のレベルで検証することには意味があり、検証の失敗を診断するためのコンテキストは非常に役立ちます。 MongoDBの課題トラッカーで監視/賛成投票できる関連するオープン機能リクエストがあります。 SERVER-20547:操作がドキュメント検証に失敗した理由を公開してください

詳細については、以下もご覧ください ドキュメントの検証-パート1:ドキュメントに対する適切な制御量の追加 。これは、MongoDB 3.2におけるドキュメント検証の一般的な長所と短所のいくつかを強調し、validationActionおよびvalidationLevel構成オプションに基づく結果の参照表を含みます。

10
Stennie

もちろん、元の答えは正しいですが、dbに到達する前に検証を処理することが絶対にベストプラクティスですが、今のようにそれを追跡する必要がある場合は、スキーマから検証を一時的に削除して、何が表示されるかを確認できます。コレクションでアップ。

フィールドが必須であるにもかかわらず、欠落、空、または奇形が表示されている場合は、検索範囲が狭くなります。データが正しい場合は、スキーマで指定されている検証を確認してください。

1
Serexx