Làm cách nào để xác định lý do tại sao tài liệu MongoDB không xác thực?

13

Làm cách nào để xác định lý do tại sao chèn tài liệu MongoDB không xác thực? Tất cả những gì tôi nhận được là một writeError có nội dung "Xác thực tài liệu không thành công", điều này không hữu ích lắm.

(Điều này xảy ra thường xuyên và tôi muốn hiểu cách gỡ lỗi chính xác, thay vì yêu cầu trợ giúp với một ví dụ cụ thể.)

mongodb debugging data-validation

— Jonathan Wheeler
nguồn

10

Như tại MongoDB 3.2, không có phản hồi nào về lý do xác thực tài liệu không thành công: biểu thức xác thực tổng thể hiện đang đánh giá là Đúng ("OK") hoặc Sai ("Xác thực tài liệu không thành công"). Hành vi xác nhận có thể được điều chỉnh với các tùy chọn cấu hình validationAction(lỗi / cảnh báo) và validationLevel(nghiêm ngặt / trung bình / tắt), nhưng điều này không cung cấp bất kỳ bối cảnh nào nữa cho các lỗi xác thực.

Nếu bạn muốn có phản hồi chi tiết hơn, cách tiếp cận được đề xuất là thêm logic xác thực vào ứng dụng của bạn thay vì chỉ dựa vào kiểm tra phía máy chủ. Ngay cả với xác thực phía máy chủ, nhiều kiểm tra được thực hiện tốt nhất trong logic nghiệp vụ ứng dụng để giảm thiểu các chuyến đi khứ hồi đến máy chủ cơ sở dữ liệu và cung cấp phản hồi phản hồi nhanh hơn cho người dùng cuối.

Ví dụ: đầu vào của người dùng cho một ứng dụng web (các trường bắt buộc, định dạng trường, ...) phải được xác thực trong trình duyệt trước khi được gửi tới ứng dụng của bạn hoặc cố gắng chèn / cập nhật vào cơ sở dữ liệu.

Tuy nhiên, sẽ hợp lý khi xác nhận ở nhiều cấp độ để đảm bảo chất lượng dữ liệu và một số bối cảnh để chẩn đoán lỗi xác thực sẽ rất hữu ích. Có một yêu cầu tính năng mở có liên quan mà bạn có thể xem / bỏ phiếu trong trình theo dõi vấn đề MongoDB: SERVER-20547: Đưa ra lý do một hoạt động không xác thực tài liệu .

Để biết thêm thông tin, bạn cũng có thể quan tâm đến Xác thực tài liệu - Phần 1: Thêm số lượng quyền kiểm soát đối với tài liệu của bạn . Điều này nêu bật một số ưu và nhược điểm chung của xác thực tài liệu như tại MongoDB 3.2 và bao gồm bảng tham chiếu cho kết quả dựa trên các tùy chọn cấu hình validationActionvà validationLevel.

— Stennie
nguồn

2

Cảm ơn! Đoán tôi đã không thiếu bất cứ điều gì ở đây. Chúng tôi thực sự thực hiện hầu hết xác thực trong ứng dụng của mình, nhưng chúng tôi để lại các kiểm tra cấp thấp với tư cách là trình xác nhận MongoDB, chủ yếu là để đảm bảo các kỹ sư phần mềm của chúng tôi (và bản thân tôi) không tạo ra lỗi trong quá trình phát triển, thay vì tìm lỗi người dùng trong sản xuất. Tôi đã bình chọn JIRA. Chúc mừng!

— Jonathan Wheeler

Vấn đề là định dạng lược đồ là "bán chuẩn", tức là với các phần mở rộng MongoDB, vì vậy vẫn khó tìm ra nguyên nhân sử dụng các trình xác thực Lược đồ JSON tiêu chuẩn.

— Hendy I Girls

1

@HendyIINA Có, có một vài phần mở rộng cho Lược đồ JSON cho các kiểu dữ liệu MongoDB để xác thực hoặc chuyển đổi khách hàng bổ sung sẽ được yêu cầu để xác thực nghiêm ngặt. Tôi đã thấy một vài ví dụ như mongo-schemercho Node.js, được xây dựng trên AJV (Trình xác thực lược đồ JSON khác) .

— Stennie

1

Tất nhiên câu trả lời ban đầu là đúng, xử lý xác thực trước khi đến db là hoàn toàn tốt nhất, nhưng như một vấn đề thực tế nếu bạn cần đuổi theo nó ngay bây giờ, bạn có thể tạm thời xóa xác thực khỏi Schema và sau đó xem những gì hiển thị lên trong Bộ sưu tập.

Nếu một trường được yêu cầu nhưng nó hiển thị bị thiếu, trống hoặc bị sai thì ít nhất nó sẽ thu hẹp tìm kiếm của bạn. Nếu dữ liệu có vẻ đúng, hãy xem các xác nhận được chỉ định trong Lược đồ.

— Serexx
nguồn