MongoDB: التحقق من صحة المخطط

التحقق من صحة المخطط هو عملية التحقق من صحة البيانات على مستوى قاعدة البيانات — حيث يمكنه استبعاد البيانات غير الصحيحة حتى في غياب طبقة التطبيق.

القيمة الفريدة للتحقق من الصحة على مستوى قاعدة البيانات: لماذا يظل التحقق من صحة المخطط ضروريًّا حتى مع وجود أدوات التحقق من Mongoose؟ لأن التحقق من صحة Mongoose لا يسري إلا على مستوى طبقة التطبيق— 1. التكامل بين التطبيقات المتعددة: إذا كانت هناك خدمات صغيرة متعددة (Node.js/Python/Go) تكتب إلى نفس قاعدة بيانات MongoDB، لكن خدمة Node.js هي الوحيدة التي تستخدم التحقق من صحة Mongoose بينما لا تستخدمه الخدمات الأخرى؛ 2. العمليات المباشرة على قاعدة البيانات: تتجاوز فرق العمليات التي تستخدم Mongo shell لإصلاح البيانات أو نصوص ETL التي تكتب مباشرةً إلى قاعدة البيانات أدوات التحقق من Mongoose؛ 3. الدفاع المتعدد المستويات: حتى في حالة وجود أخطاء في التحقق على مستوى التطبيق، لا يزال بإمكان مستوى قاعدة البيانات اعتراضها. يُعد التحقق من المخطط خط الدفاع الأخير — فهو لا يتم تشغيله في الظروف العادية (نظرًا لأن مستوى التطبيق قد اعترض المشكلات بالفعل)، ولكنه يحمي سلامة البيانات في الحالات الاستثنائية.

القيود والحلول البديلة للتحقق من صحة المخطط: يتسم التحقق من صحة المخطط في MongoDB بقيود واضحة — 1. لا يدعم التحقق من الصحة عبر الحقول (على سبيل المثال، "endDate > startDate")، وهو ما يجب معالجته على مستوى طبقة التطبيق؛ 2. لا يدعم التحقق غير المتزامن (مثل "يجب أن يكون اسم المستخدم فريدًا"، وهو ما يتطلب البحث في قاعدة البيانات)، وهو ما يجب معالجته باستخدام فهرس فريد؛ 3. لا يدعم التحقق الشرطي (على سبيل المثال، “author مطلوب عندما يكون type='book'”)، والذي يجب معالجته على مستوى طبقة التطبيق؛ 4. لا يدعم $jsonSchema جميع عوامل MongoDB (على سبيل المثال، $regex مقيد). لذلك، لا يمكن للتحقق من صحة المخطط أن يحل محل التحقق من صحة طبقة التطبيق بالكامل — فالنهج الصحيح هو أن تتولى طبقة التطبيق إجراء التحقق الشامل (رسائل الخطأ سهلة الفهم، والمنطق عبر الحقول، والتحقق غير المتزامن)، بينما تتولى طبقة قاعدة البيانات إجراء التحقق الاحتياطي (الحقول الإلزامية، وأنواع البيانات، والنطاقات، والتفرد).

1. ما ستتعلمه

• أداة التحقق من صحة $jsonSchema
• إجراء أداة التحقق (خطأ / تحذير)
• مستوى التحقق (صارم / معتدل)
• مقارنة بين مخطط مونغوس (mongoose Schema) و$jsonSchema في MongoDB
• استراتيجية تطوير المخطط

graph LR
    A[Client-Side Document Insertion] --> B{mongo<br/>Schema Validation}
    B -->|validationLevel<br/>strict/moderate| C{Validation Rules}
    C -->|bsonType| D[Type Checking]
    C -->|required| E[Required Checks]
    C -->|pattern| F[Regular Expression Validation]
    C -->|enum| G[Enumeration Check]
    C -->|minLength| H[Length Check]

    D --> I{Through?}
    E --> I
    F --> I
    G --> I
    H --> I

    I -->|Yes + action=error| J[✅ Insertion successful]
    I -->|No + action=error| K[❌ Reject + Throw error]
    I -->|No + action=warn| L[⚠️ Allow + Warning]

    style J fill:#d4edda
    style K fill:#f8d7da

graph LR
    A[Client-Side Document Insertion] --> B{mongo<br/>Schema Validation}
    B -->|validationLevel<br/>strict/moderate| C{Validation Rules}
    C -->|bsonType| D[Type Checking]
    C -->|required| E[Required Checks]
    C -->|pattern| F[Regular Expression Validation]
    C -->|enum| G[Enumeration Check]
    C -->|minLength| H[Length Check]

    D --> I{Through?}
    E --> I
    F --> I
    G --> I
    H --> I

    I -->|Yes + action=error| J[✅ Insertion successful]
    I -->|No + action=error| K[❌ Reject + Throw error]
    I -->|No + action=warn| L[⚠️ Allow + Warning]

    style J fill:#d4edda
    style K fill:#f8d7da

2. أداة التحقق من صحة $jsonSchema

شرح المفهوم: $jsonSchema هي لغة للتحقق من صحة مخطط المستندات تم تقديمها في الإصدار 3.6 وما بعده من MongoDB، وهي تستند إلى مواصفات JSON Schema. تتيح لك هذه اللغة تحديد القواعد الهيكلية التي يجب أن تستوفيها المستندات على مستوى قاعدة البيانات — مثل أنواع الحقول، والحقول الإلزامية، ونطاقات القيم، وأنماط التعبيرات العادية. وعلى عكس التحقق من الصحة على مستوى طبقة التطبيق، يتم فرض $jsonSchema بواسطة محرك MongoDB، ويجب على أي عميل (Python، Java، Node.js) يقوم بكتابة البيانات الامتثال له.

كيفية العمل: عند إنشاء مجموعة باستخدام أداة التحقق من الصحة، يقوم MongoDB بتخزين قواعد $jsonSchema في بيانات تعريف المجموعة. وفي كل عملية إدراج أو تحديث، يقوم المحرك تلقائيًا بالتحقق مما إذا كان المستند يستوفي القواعد قبل كتابته. وفي حالة فشل عملية التحقق من الصحة، يقرر النظام ما إذا كان سيقوم بإصدار خطأ ورفض العملية أم تسجيل تحذير بناءً على قيمة validationAction.

الكلمات الأساسية في $jsonSchema:

العلاقة بين $jsonSchema و JSON Schema: تستند ميزة $jsonSchema في MongoDB إلى مواصفات JSON Schema Draft 4، ولكن هناك عدة اختلافات رئيسية — 1. يستخدم bsonType بدلاً من type (لأن JSON Schema لا يميز بين أنواع BSON مثل int وdouble وdecimal وobjectId)؛ 2. يتم تعيين additionalProperties إلى true افتراضيًا (مما يسمح بالحقول غير المُعرَّفة، وهو ما يختلف عن الإعداد الافتراضي في JSON Schema Draft 4)؛ 3. لا يدعم المراجع $ref (يجب تعريف جميع القواعد في النص نفسه)؛ 4. لا يدعم format (على سبيل المثال، email، uri، date-time؛ يجب استخدام التعبيرات النمطية بدلاً من ذلك). إن فهم هذه الاختلافات يساعد على تجنب الارتباك الناتج عن «نسخ الكود حرفياً من أحد دروس JSON Schema لتواجه أخطاءً بعد ذلك».

التحقق من صحة العناصر المتداخلة باستخدام $jsonSchema: يدعم $jsonSchema التحقق التكراري من صحة الكائنات والمصفوفات المتداخلة — 1. بالنسبة للكائنات المتداخلة، قم بتعريف البنية الفرعية باستخدام properties وrequired (على سبيل المثال، address: {bsonType: 'object', required: ['city'], properties: {city: {bsonType: 'string'}}})؛ 2. بالنسبة للمصفوفات، استخدم items لتعريف قواعد العناصر (على سبيل المثال، tags: {bsonType: 'array', items: {bsonType: 'string'}} للتحقق من أن جميع عناصر المصفوفة هي سلاسل نصية)؛ 3. لا يوجد حد صارم لعمق التداخل، لكن التداخل المفرط قد يؤثر على أداء التحقق وقابلية القراءة — فكر في تقسيمها إلى مجموعات منفصلة إذا تجاوزت مستويات التداخل ثلاثة مستويات. يُعد التحقق المتداخل ميزة أساسية لنموذج المستند — ففي حين يتطلب SQL عمليات ربط (JOIN) متعددة الجداول للتحقق من صحة البيانات ذات الصلة، يقوم MongoDB بالتحقق من صحة شجرة المستند بأكملها في مسار واحد.

حالات الاستخدام:

• حماية هياكل البيانات الحيوية (المستخدمون، الطلبات، سجلات الدفع)
• التحقق الموحد من صحة قواعد البيانات المشتركة في الخدمات الصغيرة متعددة اللغات
• منع كتابة البيانات غير الصحيحة (كإجراء احتياطي في حالة فشل عملية التحقق من صحة البيانات على مستوى طبقة التطبيق)
• غير مناسب لـ: عمليات التحقق التي تتطلب معالجة غير متزامنة، أو عمليات التحقق عبر مجموعات متعددة، أو عمليات التحقق التي تنطوي على منطق أعمال معقد

العلاقة بين مواصفة $jsonSchema ومواصفة JSON Schema: تستند $jsonSchema في MongoDB إلى مواصفات JSON Schema Draft 4، لكنها تتضمن امتدادات BSON — حيث تستبدل type بـ bsonType (نظرًا لأن MongoDB تستخدم BSON بدلاً من JSON للأنواع) وتضيف أنواعًا خاصة بـ BSON مثل objectId وdecimal وdate. من المهم فهم هذه العلاقة: 1. bsonType: 'string' يقابل type: 'string' في JSON Schema؛ 2. bsonType: 'int' ليس له نظير مباشر (يحتوي JSON على number فقط)؛ 3. تتطابق required وproperties وpattern وenum مع تلك الموجودة في JSON Schema.

استراتيجية ترحيل الإصدارات: تتطلب التغييرات في التحقق من صحة المخطط استراتيجية لإدارة الإصدارات — 1. إضافة حقول اختيارية: مخاطر منخفضة؛ النشر مباشرةً مع تعيين «معتدل» + «تحذير»؛ 2. إضافة حقول إلزامية: مخاطر متوسطة؛ تعيينها أولاً على «اختياري» → تنفيذ ترحيل البيانات → ثم تعيينها على «إلزامي»؛ 3. تغيير أنواع الحقول: مخاطر عالية؛ الحقول ذات الكتابة المزدوجة → الترحيل → التبديل → حذف الحقول القديمة؛ 4. تضييق نطاقات القيم: مخاطر متوسطة — المراقبة أولاً باستخدام «معتدل» و«تحذير» → التأكد من عدم وجود انتهاكات واسعة النطاق → التبديل إلى «خطأ». تسجيل القواعد القديمة لكل تغيير؛ التراجع باستخدام collMod إذا لزم الأمر.

// === Create a collection with validation ===
db.createCollection('users', {
  validator: {
    $jsonSchema: {
      bsonType: 'object',
      required: ['email', 'username'],
      properties: {
        email: {
          bsonType: 'string',
          pattern: '^.+@.+$',
          maxLength: 100
        },
        username: {
          bsonType: 'string',
          minLength: 3,
          maxLength: 30
        },
        age: {
          bsonType: 'int',
          minimum: 0,
          maximum: 150
        },
        role: {
          enum: ['customer', 'admin', 'moderator']
        },
        isActive: {
          bsonType: 'bool'
        }
      }
    }
  },
  validationLevel: 'strict',
  validationAction: 'error'
});

تحليل النقاط الرئيسية:

1. bsonType على عكس type في JSON Schema، تستخدم MongoDB أسماء أنواع BSON (مثل 'int' بدلاً من 'number')
2. required هي كلمة رئيسية من المستوى الأعلى، وقيمتها عبارة عن مصفوفة من أسماء الحقول؛ وهي لا تنتمي إلى أي خاصية.
3. يتم تعريف المستندات المتداخلة باستخدام properties، بينما يتم تعريف عناصر المصفوفة باستخدام items

أنماط التصميم للتحقق المتداخل: توجد ثلاثة أنماط تصميم للتحقق المتداخل في $jsonSchema: 1. النمط المضمن بالكامل (حيث يتم تداخل address وitem مباشرةً داخل $jsonSchema التابع لـ order؛ وهذا يوفر بنية واضحة ولكنه يؤدي إلى كود مطول)؛ 2. نمط استخراج المتغيرات (حيث يتم تعريف addressSchema وitemSchema كمتغيرات JavaScript ويتم الإشارة إليهما في المخطط الرئيسي؛ وهذا يوفر قابلية جيدة لإعادة استخدام الكود ولكنه يتطلب إدارة على مستوى طبقة التطبيق)؛ 3. الوضع الهجين (يتم تضمين الحقول الأساسية، بينما يتم استخراج الهياكل الفرعية القابلة لإعادة الاستخدام كمتغيرات). يُوصى باستخدام الوضع 3 في بيئات الإنتاج — نظرًا لأن العناوين وعناصر الطلبات قد تُعاد استخدامها عبر مجموعات متعددة (فكل من الطلبات والمستخدمين لديهم عناوين)، فإن استخراجها كمتغيرات مستقلة يقلل من التعريفات الزائدة عن الحاجة.

الحالات الاستثنائية في التحقق من صحة المصفوفات: توجد عدة حالات استثنائية معرضة للخطأ في التحقق من صحة المصفوفات باستخدام $jsonSchema — 1. minItems وmaxItems تتحققان من طول المصفوفة بدلاً من عدد المستندات (المصفوفة الفارغة [] تجتاز minItems: 0 لكنها تفشل في minItems: 1)؛ 2. items تحدد القواعد لجميع العناصر (وهي لا تدعم التحقق من صحة التوبول حيث «تكون العناصر الثلاثة الأولى من أنواع مختلفة»؛ تدعم مسودة JSON Schema 4 هذا الأمر، لكن MongoDB لا تدعمه)؛ 3. uniqueItems: true تتحقق من تفرد عناصر المصفوفة، لكنها قد لا تعمل كما هو متوقع مع الكائنات المتداخلة (يتم مقارنة الكائنات بالمرجع بدلاً من العمق)؛ 4. المصفوفة الفارغة مقابل المصفوفة ذات القيمة null — المصفوفة الفارغة [] تجتاز التحقق من الصحة باستخدام bsonType: 'array'، لكن null لا تجتازه (يتطلب bsonType: ['array', 'null'] للسماح بـ null).

▶ المثال 1: المستندات المتداخلة + التحقق من صحة المصفوفات

// ShopHub Order Collection:Nested Addresses + Validation of the Order Items Array
db.createCollection('orders', {
  validator: {
    $jsonSchema: {
      bsonType: 'object',
      required: ['userId', 'items', 'total', 'address'],
      properties: {
        userId: { bsonType: 'objectId' },
        items: {
          bsonType: 'array',
          minItems: 1,
          items: {
            bsonType: 'object',
            required: ['productId', 'qty', 'price'],
            properties: {
              productId: { bsonType: 'objectId' },
              qty: { bsonType: 'int', minimum: 1 },
              price: { bsonType: 'decimal', minimum: 0 }
            }
          }
        },
        address: {
          bsonType: 'object',
          required: ['street', 'city', 'zipCode'],
          properties: {
            street: { bsonType: 'string', minLength: 1 },
            city: { bsonType: 'string' },
            zipCode: { bsonType: 'string', pattern: '^[0-9]{5,10}$' }
          }
        },
        total: { bsonType: 'decimal', minimum: 0 }
      }
    }
  },
  validationLevel: 'moderate',
  validationAction: 'error'
});

// Test:Valid Orders
db.orders.insertOne({
  userId: ObjectId(),
  items: [{ productId: ObjectId(), qty: Int32(2), price: Decimal128('29.99') }],
  address: { street: '123 Main St', city: 'Seattle', zipCode: '98101' },
  total: Decimal128('59.98')
});
// ✅ Success

// Test: Empty items Array
db.orders.insertOne({
  userId: ObjectId(),
  items: [],
  address: { street: '123 Main St', city: 'Seattle', zipCode: '98101' },
  total: Decimal128('0')
});
// ❌ Document failed validation (minItems: 1)

الإخراج:

TEXT 📖 للعرض فقط

📋 Copy

الإدراج الناجح: { acknowledged: true, insertedId: ObjectId('...') }
الإدراج الفاشل: Document failed validation (items مصفوفة فارغة، minItems: 1)

3. validationAction

وصف المفهوم: validationAction يتحكم في سلوك MongoDB عند فشل عملية التحقق من الصحة — سواء برفض العملية بشكل قاطع (خطأ) أو السماح بها مع إصدار تحذير (تحذير). ويُعد هذا مفاضلة حاسمة بين سلامة البيانات واستمرارية الأعمال.

كيف يعمل:

• error الوضع: يُصدر خطأً من نوع DocumentFailedValidation عند فشل عملية التحقق من الصحة؛ ويتم التراجع عن عملية الكتابة، ويتلقى العميل استثناءً.
• warn الوضع: تستمر عمليات الكتابة بنجاح حتى في حالة فشل التحقق من الصحة، ولكن يتم تسجيل رسالة تحذير في سجل mongod؛ مناسب للتطبيق التدريجي

القيمة التشغيلية لوضع «التحذير»: تتمثل القيمة الأساسية لوضع «التحذير» في «نشر القواعد الجديدة دون أي مخاطر» — عند إضافة قاعدة تحقق جديدة، قم بتعيينها على وضع «التحذير» أولاً، وراقب السجلات لمدة أسبوع إلى أسبوعين، وتابع عدد عمليات الكتابة الحالية التي تم رفضها. إذا كان معدل المخالفة أقل من 1٪، تُعتبر القاعدة آمنة ويمكن تحويلها إلى وضع error؛ أما إذا كان معدل المخالفة أكبر من 5٪، فيجب تعديل القاعدة أو تنظيف البيانات التاريخية أولاً. تمنع استراتيجية النشر التدريجي هذه وقوع حوادث في بيئة الإنتاج مثل «الأخطاء واسعة النطاق فور النشر». لاستعلام سجلات warn، استخدم db.adminCommand({getLog: 'global'}) وقم بتصفية النتائج باستخدام الكلمة الرئيسية DocumentFailedValidation.

حل المراقبة لسجلات "warn": تتطلب سجلات الوضع "warn" مراقبة استباقية — 1. تصفية السجلات: تختلط سجلات "warn" في MongoDB مع السجلات الأخرى؛ بعد جمعها عبر Filebeat/Fluentd، قم بتصفية السجلات بحثًا عن الكلمة المفتاحية "DocumentFailedValidation"؛ 2. قواعد التنبيه: إذا تجاوز عدد الانتهاكات 10 انتهاكات في الساعة، فقم بتشغيل تنبيه عبر Slack أو البريد الإلكتروني (مما يشير إلى أن القاعدة قد تكون صارمة للغاية)؛ 3. لوحة معلومات الانتهاكات: قم بتجميع الانتهاكات وحسابها حسب المجموعة والحقل ونوع الخطأ لتحديد القواعد التي تحتاج إلى تعديل؛ 4. إعداد التقارير الآلي: قم بإنشاء تقرير ملخص يومي للانتهاكات (Z انتهاكًا في الحقل Y من المجموعة X) وأرسله إلى مسؤول قاعدة البيانات وفرق الخلفية. لا يُعد وضع «التحذير» نهجًا من نوع «اضبطه وانسه»، بل هو نهج من نوع «اضبطه وراقبه عن كثب» — فلا يمكنك الانتقال بأمان من وضع «التحذير» إلى وضع «الخطأ» إلا من خلال المراقبة المستمرة.

حالات الاستخدام:

graph LR
    A[Write Operation] --> B{Schema Validation}
    B -->|Through| C[✅ Write successful]
    B -->|Failure + action=error| D[❌ Throw Error, Reject]
    B -->|Failure + action=warn| E[⚠️ Write successful + Log Warning]

    style C fill:#d4edda
    style D fill:#f8d7da
    style E fill:#fff3cd

graph LR
    A[Write Operation] --> B{Schema Validation}
    B -->|Through| C[✅ Write successful]
    B -->|Failure + action=error| D[❌ Throw Error, Reject]
    B -->|Failure + action=warn| E[⚠️ Write successful + Log Warning]

    style C fill:#d4edda
    style D fill:#f8d7da
    style E fill:#fff3cd

// === error Pattern(Recommended Production)===
db.createCollection('users', {
  validator: { $jsonSchema: {...} },
  validationAction: 'error'
});

// === warn Pattern (Lenient) ===
db.createCollection('users', {
  validator: { $jsonSchema: {...} },
  validationAction: 'warn'
});
// Inserting an Incompatible Document:Success + Warning Log

تحليل النقاط الرئيسية:

1. قبل التبديل من «تحذير» إلى «خطأ»، نوصي أولاً بتحليل تواتر المخالفات في سجلات «التحذير».
2. يمكن الاطلاع على السجلات في وضع التحذير عبر db.adminCommand({getLog:'global'})
3. validationAction: 'off' غير موجود؛ لتعطيل عملية التحقق من الصحة، قم بتعيين validationLevel: 'off'

4. مستوى التحقق من الصحة

وصف المفهوم: يحدد validationLevel المستندات التي تنطبق عليها قواعد التحقق من الصحة — سواء كانت المستندات الجديدة فقط (متوسط) أو بما في ذلك المستندات الموجودة (صارم). ويُعد هذا إعدادًا أساسيًّا لتطوير المخطط، ويحدد كيفية تأثير القواعد الجديدة على البيانات الموجودة.

كيف يعمل:

• strict: يتم التحقق من صحة جميع جمل INSERT وUPDATE، بما في ذلك عند تعديل المستندات الموجودة.
• moderate: يتم إجراء التحقق من الصحة فقط على المستندات التي تم إدراجها حديثًا وعلى التحديثات التي تُجرى على المستندات التي تستوفي قواعد التحقق من الصحة بالفعل؛ أما التحديثات التي تُجرى على المستندات القديمة التي لا تستوفي هذه القواعد، فلا يتم التحقق من صحتها.
• off: تعطيل عملية التحقق من الصحة تمامًا

حالات الاستخدام:

// === moderate Pattern(Recommendations)===
db.createCollection('users', {
  validator: { $jsonSchema: {...} },
  validationLevel: 'moderate'
});
// Existing dirty data is not validated，Validate only new data

تحليل النقاط الرئيسية:

1. يُعد المستوى «المعتدل» هو الأكثر استخدامًا في بيئات الإنتاج؛ فهو لا يمنع تحديث البيانات القديمة التي تم تعديلها.
2. قبل التبديل من «معتدل» إلى «صارم»، يجب عليك أولاً تنقية البيانات التاريخية غير المتوافقة.
3. collMod يمكنك تعديل validationLevel ديناميكيًا دون الحاجة إلى إعادة إنشاء المجموعة.

المخاطر الكامنة في الوضع «المعتدل»: قد يبدو نهج «التحقق من صحة البيانات الجديدة فقط» في الوضع «المعتدل» آمنًا، لكنه ينطوي على مخاطر كامنة — 1. يمكن تحديث البيانات القديمة عددًا غير محدود من المرات دون تشغيل عملية التحقق من الصحة، مما قد يؤدي إلى تفاقم تلف البيانات غير الصحيحة؛ 2. قد يعتمد كود التطبيق على قواعد المخطط (مثل افتراض أن جميع المستندات تحتوي على حقل email)، مما يتسبب في تعطل التطبيق عندما لا تتوافق البيانات القديمة مع هذه القواعد؛ 3. الوضع «المعتدل» ليس «إعدادًا افتراضيًا آمنًا»، بل هو «فترة سماح للترحيل» — يجب عليك التبديل إلى الوضع «الصارم» بمجرد اكتمال عملية الترحيل. أفضل الممارسات: ابدأ بـ «متوسط» + «تحذير» لمراقبة معدل الانتهاكات، ثم قم بالتبديل إلى «صارم» + «خطأ» بمجرد انخفاض معدل الانتهاكات إلى 0.

تنسيق عملية ترحيل البيانات والتحقق من صحتها: يجب تنسيق عملية التحقق من صحة المخطط وترحيل البيانات — 1. عند إضافة حقل إلزامي جديد، قم أولاً بتعيين قيمة افتراضية (لمنع فقدان الحقول الإلزامية في المستندات القديمة)، ثم استخدم برنامج نصي للترحيل لتعبئة البيانات التاريخية؛ 2. عند إضافة قيد قائمة التعداد، تأكد أولاً من أن جميع القيم التاريخية تقع ضمن نطاق القائمة (وإلا، يمكن تحديث البيانات القديمة في الوضع المعتدل، لكن ذلك سيؤدي إلى حدوث خطأ في الوضع الصارم)؛ 3. عند تشديد القيود (على سبيل المثال، تغيير maxlength من 200 إلى 100)، راقب أولاً السلوك في الوضع warn للتأكد من عدم وجود بيانات طويلة بشكل مفرط قبل التبديل إلى الوضع error. عادةً ما تستخدم نصوص الترحيل bulkWrite + $set لتحديث البيانات التاريخية دفعة واحدة.

5. تعديل أداة التحقق لمجموعة موجودة بالفعل

شرح المفهوم: في بيئة الإنتاج، لا تكون المخططات ثابتة — فقد تتطلب التغييرات في العمليات التجارية إضافة حقول جديدة، أو تعديل القواعد، أو حتى إزالة القيود. يتيح لك الأمر collMod تعديل أدوات التحقق من صحة المجموعات الموجودة أثناء التشغيل، دون الحاجة إلى إعادة إنشاء المجموعة أو إيقاف الخدمة مؤقتًا.

ملاحظات مهمة حول collMod: يقوم أداة التحقق من صحة collMod بإجراء «استبدال كامل» بدلاً من «دمج تدريجي» — يجب عليك تقديم مخطط $jsonSchema الكامل مع كل استدعاء، حتى لو كنت تقوم بتغيير حقل واحد فقط. وهذا يعني: 1. يجب عليك حفظ المخطط الحالي قبل إجراء التغييرات (استخدم db.getCollectionInfos() لعرض أداة التحقق الحالية)؛ 2. يجب أن يتضمن المخطط الجديد جميع الحقول الموجودة في المخطط القديم (وإلا، فلن يتم التحقق من صحة الحقول غير المدرجة بعد الآن)؛ 3. يُنصح بإدارة قواعد $jsonSchema باستخدام نظام التحكم في الإصدارات (مثل Git) لتسهيل عمليات التراجع والتدقيق. لإزالة أداة التحقق من الصحة، استخدم كائنًا فارغًا { } مع validationLevel: 'off'، بدلاً من حذف حقل أداة التحقق من الصحة.

ممارسات التحكم في إصدارات المخططات: يجب إدراج تعريفات $jsonSchema في نظام التحكم في الإصدارات — 1. ملف JSON واحد لكل مجموعة (على سبيل المثال، validators/users.json، validators/orders.json)، تُدار في نفس المستودع الذي يحتوي على كود التطبيق؛ 2. يجب أن تُنفذ نصوص النشر collMod وفقًا لترتيب التبعيات (المستخدمون أولاً، ثم الطلبات، لأن الطلبات تشير إلى users._id)؛ 3. ترقيم الإصدارات: تضمين رقم الإصدار وتاريخ التغييرات في تعليق في أعلى كل ملف مخطط لتسهيل التتبع؛ 4. إجراء التراجع: ما عليك سوى التراجع عن ملف المخطط باستخدام Git وإعادة تشغيل البرنامج النصي للنشر للتراجع؛ 5. تكامل CI/CD: قم بتنفيذ نصوص ترحيل المخطط تلقائيًا ضمن مسار النشر لضمان تحديث الكود والمخطط بشكل متزامن. هذه المجموعة من الممارسات تقضي على مشكلة النشر الكلاسيكية المتمثلة في «تغير الكود دون تغيير مخطط قاعدة البيانات».

استراتيجية تنفيذ عمليات ترحيل المخطط: يجب تنفيذ تغييرات المخطط على مراحل، تمامًا مثل الكود — 1. المرحلة 1: جعل الحقل الجديد اختياريًا (moderate + warn)، والمراقبة لمدة أسبوع إلى أسبوعين للتأكد من عدم وجود مشكلات؛ 2. المرحلة 2: استخدام نصوص ترحيل لملء البيانات التاريخية (bulkWrite + $set) لضمان احتواء جميع المستندات على الحقول الجديدة؛ 3. المرحلة 3: تعيين الحقول الجديدة على أنها مطلوبة (strict + error)، مع فرض أن المستندات الجديدة يجب أن تتضمنها؛ 4. المرحلة 4: يبدأ كود التطبيق في استخدام الحقول الجديدة (في السابق، كان الأمر «استخدامها إن وجدت، وتجاهلها إن لم تكن موجودة»). يتم نشر كل مرحلة بشكل مستقل؛ إذا ظهرت مشكلة، يتم التراجع عن المرحلة الحالية فقط. تجنب تنفيذ جميع التغييرات دفعة واحدة — على الرغم من أن «إضافة الحقول، وتعبئة البيانات التاريخية، ثم تعيينها كحقول إلزامية» قد يبدو غير فعال، إلا أن كل خطوة قابلة للتحقق منها وقابلة للتراجع عنها، مما يجعلها الطريقة الوحيدة لضمان سلامة بيئة الإنتاج.

graph LR
    A[Analyzing New Demand] --> B[Design New Rules]
    B --> C[validationLevel: moderate<br/>validationAction: warn]
    C --> D[Observation Log<br/>Frequency of Violations]
    D --> E{Many violations?}
    E -->|Many| F[Adjustment Rules/Data Migration]
    E -->|Few| G[validationAction: error]
    F --> D
    G --> H[validationLevel: strict<br/>(Optional)]

    style C fill:#fff3cd
    style G fill:#d4edda

graph LR
    A[Analyzing New Demand] --> B[Design New Rules]
    B --> C[validationLevel: moderate<br/>validationAction: warn]
    C --> D[Observation Log<br/>Frequency of Violations]
    D --> E{Many violations?}
    E -->|Many| F[Adjustment Rules/Data Migration]
    E -->|Few| G[validationAction: error]
    F --> D
    G --> H[validationLevel: strict<br/>(Optional)]

    style C fill:#fff3cd
    style G fill:#d4edda

أفضل الممارسات لتطوير المخطط: تتطلب تغييرات المخطط في بيئات الإنتاج اتباع نهج حذر وتدريجي — 1. إضافة الحقول: قم أولاً بتعيينها على أنها اختيارية مع قيمة افتراضية (بحيث يتم ملء البيانات القديمة تلقائيًا بالقيمة الافتراضية)؛ وبعد تشغيلها لفترة للتأكد من عدم وجود مشكلات، قم بتغييرها إلى "مطلوبة"؛ 2. تشديد القيود: استخدم أولاً validationAction: warn للمراقبة؛ وبعد التأكد من عدم وجود انتهاكات، قم بالتبديل إلى error؛ 3. إزالة الحقول: أولاً، أوقف الكتابة إلى الحقل على مستوى طبقة التطبيق؛ وبعد التأكد من توقف قراءة البيانات القديمة، استخدم $unset لتنظيفها بشكل جماعي؛ 4. إعادة تسمية الحقول: أولاً، أضف الحقل الجديد واكتب في كل من الحقلين الجديد والقديم في آن واحد؛ وبعد ترحيل البيانات، احذف الحقل القديم. يلزم وجود خطة تراجع لكل خطوة.

العلاقة بين $jsonSchema و JSON Schema: تستند ميزة $jsonSchema في MongoDB إلى مواصفات JSON Schema draft-4، ولكن تم تكييفها لتشمل دعمًا لـ bsonType (الذي يوسع أنواع BSON مثل ObjectId و Decimal128)، و required، و properties، و pattern، و minimum/maximum، و minItems/maxItems، وغيرها. الكلمات الرئيسية غير المدعومة: $ref (المراجع الخارجية غير مدعومة)، و definitions (التعريفات القابلة لإعادة الاستخدام غير مدعومة)، و anyOf/oneOf/allOf (التحقق المركب غير مدعوم). تعني هذه القيود أن $jsonSchema مناسب لـ «التحقق الهيكلي» (نوع الحقل + النطاق + التنسيق) ولكنه غير مناسب للتحقق المنطقي المعقد عبر الحقول — حيث يجب تنفيذ هذا الأخير على مستوى طبقة Mongoose.

// === Add a validator to an existing collection ===
db.runCommand({
  collMod: 'users',
  validator: {
    $jsonSchema: {
      bsonType: 'object',
      required: ['email', 'username'],
      properties: {
        email: { bsonType: 'string', pattern: '^.+@.+$' }
      }
    }
  },
  validationLevel: 'moderate',
  validationAction: 'error'
});

// === Modify the Validator ===
db.runCommand({
  collMod: 'users',
  validator: {
    $jsonSchema: {
      bsonType: 'object',
      required: ['email', 'username', 'age'],  // New age Required
      properties: {
        email: { bsonType: 'string', pattern: '^.+@.+$' },
        age: { bsonType: 'int', minimum: 0 }
      }
    }
  }
});

// === Remove Validator ===
db.runCommand({
  collMod: 'users',
  validator: {},
  validationLevel: 'off'
});

تحليل النقاط الرئيسية:

1. يقوم أداة التحقق الخاصة بـ collMod بإجراء استبدال كامل، وليس دمجًا — لذا يجب عليك كتابة القاعدة بالكامل في كل مرة تقوم فيها بإجراء تغيير.
2. عند إضافة حقل جديد «إلزامي»، يُنصح بالبدء بـ«متوسط + تحذير» والتحول إلى «صارم + خطأ» فقط بعد التأكد من أن البيانات الحالية مقبولة.
3. احذف أداة التحقق باستخدام كائن فارغ {}؛ ولا تحذف الحقل "validator".

6. مخطط مونغوس مقابل $jsonSchema في MongoDB

شرح المفهوم: يُعد كل من مخطط Mongoose و$jsonSchema في MongoDB طبقتين متكاملتين من آليات التحقق من صحة البيانات. يقوم Mongoose بالتحقق من صحة البيانات على مستوى طبقة التطبيق (داخل عملية Node.js)؛ وهو مرن ولكنه ينطبق فقط على عملاء Node.js. أما $jsonSchema فيقوم بالتحقق من صحة البيانات على مستوى طبقة قاعدة البيانات (داخل عملية mongod)؛ وهو صارم ولكنه ينطبق على جميع العملاء.

التحليل المقارن:

graph LR
    A[Client Request] --> B[mongoose Schema<br/>Application-Layer Validation]
    B -->|Through| C[MongoDB $jsonSchema<br/>Database-Level Validation]
    B -->|Failure| D[❌ Application Layer Rejection<br/>Custom Error Messages]
    C -->|Through| E[✅ Write successful]
    C -->|Failure| F[❌ Database Rejection<br/>DocumentFailedValidation]

    style B fill:#cce5ff
    style C fill:#d4edda
    style D fill:#f8d7da
    style F fill:#f8d7da

graph LR
    A[Client Request] --> B[mongoose Schema<br/>Application-Layer Validation]
    B -->|Through| C[MongoDB $jsonSchema<br/>Database-Level Validation]
    B -->|Failure| D[❌ Application Layer Rejection<br/>Custom Error Messages]
    C -->|Through| E[✅ Write successful]
    C -->|Failure| F[❌ Database Rejection<br/>DocumentFailedValidation]

    style B fill:#cce5ff
    style C fill:#d4edda
    style D fill:#f8d7da
    style F fill:#f8d7da

أفضل الممارسات:

• التحقق المزدوج على مستوى طبقة التطبيق (Mongoose) وطبقة قاعدة البيانات ($jsonSchema)
• استخدام Mongoose لإجراء عمليات التحقق من الصحة الديناميكية والدقيقة (مثل «قوة كلمة المرور» و«التحقق من صحة العلاقات بين الحقول»)
• استخدم $jsonSchema للتحقق الأساسي من صحة المخطط (كخيار احتياطي) لمنع عمليات الكتابة المباشرة التي تتجاوز طبقة التطبيق

▶ المثال 2: التحقق المزدوج باستخدام Mongoose و$jsonSchema

// ShopHub:Two-Factor Verification for User Registration
// 1. mongoose layer: Flexible Validation + Custom Message
const userSchema = new mongoose.Schema({
  email: {
    type: String,
    required: [true, 'Email is required'],
    match: [/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/, 'Invalid email format']
  },
  username: {
    type: String,
    required: true,
    minlength: [3, 'Username must be at least 3 characters'],
    maxlength: 30,
    validate: {
      validator: async function(v) {
        const count = await this.constructor.countDocuments({ username: v });
        return count === 0;
      },
      message: 'Username already exists'
    }
  },
  age: { type: Number, min: 18, max: 120 },
  role: { type: String, enum: ['customer', 'admin', 'moderator'], default: 'customer' }
});

// 2. $jsonSchema layer: Infrastructure Safety Net
db.runCommand({
  collMod: 'users',
  validator: {
    $jsonSchema: {
      bsonType: 'object',
      required: ['email', 'username'],
      properties: {
        email: { bsonType: 'string', pattern: '^.+@.+$' },
        username: { bsonType: 'string', minLength: 3 },
        age: { bsonType: 'int', minimum: 18 },
        role: { enum: ['customer', 'admin', 'moderator'] }
      }
    }
  },
  validationLevel: 'moderate',
  validationAction: 'error'
});

// 3. Effect: Node.js client uses double verification, other clients are caught by $jsonSchema safety net

الإخراج:

TEXT 📖 للعرض فقط

📋 Copy

الإدراج الناجح: { acknowledged: true, insertedId: ObjectId('...') }
الإدراج الفاشل (البريد الإلكتروني غير صالح): Document failed validation
الإدراج الفاشل (اسم المستخدم موجود مسبقًا): Username already exists

7. استراتيجية تطوير المخطط

شرح المفهوم: يُعد تطور المخطط التحدي التشغيلي الأساسي لقاعدة بيانات MongoDB الخالية من المخططات. وعلى الرغم من أن MongoDB لا تتطلب مخططًا محددًا مسبقًا، فإن البيانات في بيئة الإنتاج تتمتع دائمًا ببنية ضمنية. وعندما تتغير متطلبات العمل، يجب تعديل قواعد التحقق من الصحة بطريقة آمنة دون تعطيل العمليات التجارية.

مبادئ التطور:

1. التدريجي: اختياري في البداية، إلزامي لاحقًا؛ تحذير أولًا، خطأ لاحقًا
2. التوافق: تتوافق القواعد الجديدة مع البيانات الحالية ولا تؤدي إلى إتلافها بأثر رجعي.
3. إمكانية التراجع: يتم تسجيل كل تغيير وفقًا للقواعد القديمة، مما يتيح التراجع السريع عن التغيير إذا لزم الأمر
4. البيانات أولاً: قم بنقل البيانات أولاً، ثم شدد القواعد

قائمة مراجعة للتطوير الآمن للمخطط: تنطوي أنواع التغييرات المختلفة في المخطط على مستويات متفاوتة من المخاطر — 1. العمليات الآمنة (يمكن تنفيذها مباشرةً): إضافة حقول اختيارية، وزيادة maxLength، وتقليل minimum، وإضافة قيم قائمة التعداد، وإضافة السمة $jsonSchema (دون تغيير required)؛ 2. تتطلب الحذر (يلزم ترحيل البيانات أولاً): إضافة حقل إلزامي، تشديد minLength/الحد الأدنى، إزالة قيم التعداد، تغيير bsonType؛ 3. مخاطر عالية (يلزم تقييم شامل): إزالة الحقول، تغيير دلالات الحقول (على سبيل المثال، تغيير «العمر» من «العمر» إلى «سنة الميلاد»)، تغيير نوع الحقل الإلزامي. يمكن تنفيذ العمليات الآمنة مباشرةً في بيئة الإنتاج؛ أما العمليات التي تتطلب الحذر فيجب التحقق من صحتها أولاً في بيئة الاختبار؛ وتتطلب العمليات عالية المخاطر خطة ترحيل شاملة، واستراتيجية للتراجع، ونشرًا تدريجيًّا.

إرشادات التعاون بين الفرق لتطوير المخطط: تتطلب تغييرات المخطط مشاركة عدة فرق — 1. فريق الخلفية: تحديد قواعد المخطط + كتابة نصوص الترحيل؛ 2. فريق الواجهة الأمامية: تكييف النماذج وعمليات العرض لاستيعاب الحقول الجديدة؛ 3. فريق إدارة قواعد البيانات: تنفيذ collMod + مراقبة أداء قاعدة البيانات؛ 4. فريق ضمان الجودة: التحقق من صحة نصوص الترحيل + وضع خطط التراجع. عملية التعاون: 1. يقدم فريق الخلفية طلب سحب (PR) لتغييرات المخطط (بما في ذلك نصوص الترحيل ونصوص التراجع)؛ 2. يقدم فريق الواجهة الأمامية طلب سحب (PR) للمزامنة والتكييف؛ 3. تؤكد مراجعة الكود نطاق التغييرات؛ 4. تنفيذ الترحيل والتحقق من صحة العملية في بيئة الاختبار؛ 5. النشر في بيئة الإنتاج عبر النشر التدريجي (البدء بالأخطاء من فئة «تحذير»، ثم الأخطاء من فئة «خطأ»)؛ 6. المراقبة لمدة أسبوع إلى أسبوعين للتأكد من عدم وجود أي حالات شاذة. تمنع هذه العملية الموحدة حدوث مشكلات في التعاون مثل «تم تغيير المخطط، لكن فريق الواجهة الأمامية لم يكن على علم بذلك».

الأنماط التطورية الشائعة:

(1) إضافة حقل جديد (متوافق مع الإصدارات السابقة)

// ✅ Gradual Evolution:The default field is optional.
db.runCommand({
  collMod: 'users',
  validator: {
    $jsonSchema: {
      bsonType: 'object',
      required: ['email', 'username'],  // The old field is still required
      properties: {
        email: { bsonType: 'string' },
        username: { bsonType: 'string' },
        age: { bsonType: 'int' }  // Add a Field (not required)
      }
    }
  },
  validationLevel: 'moderate'
});

(2) تعديل نوع الحقل (يتطلب ترحيل البيانات)

عملية تغيير نوع الحقل:

graph LR
    A[1.Add a New Field<br/>bsonType:New Type] --> B[2.Dual Writing<br/>The application writes to both new and existing fields simultaneously]
    B --> C[3.Data Migration<br/>Old Field→New Field]
    C --> D[4.Switch Query<br/>Read New Field]
    D --> E[5.Delete Old Fields<br/>Confirm that there are no dependencies]

    style A fill:#cce5ff
    style E fill:#d4edda

graph LR
    A[1.Add a New Field<br/>bsonType:New Type] --> B[2.Dual Writing<br/>The application writes to both new and existing fields simultaneously]
    B --> C[3.Data Migration<br/>Old Field→New Field]
    C --> D[4.Switch Query<br/>Read New Field]
    D --> E[5.Delete Old Fields<br/>Confirm that there are no dependencies]

    style A fill:#cce5ff
    style E fill:#d4edda

// ⚠️ Exercise Caution When Changing Field Types
// 1. Add a dual-write field
db.runCommand({
  collMod: 'users',
  validator: { /* Add a New Field，Keep the old field */ }
});

// 2. Data Migration Script
db.users.find({ ageStr: { $exists: true } }).forEach(doc => {
  db.users.updateOne(
    { _id: doc._id },
    { $set: { age: parseInt(doc.ageStr) }, $unset: { ageStr: '' } }
  );
});

// 3. Remove the old field validation

8. التدريب العملي الشامل

نظرة عامة على المفهوم: يدمج «التطبيق العملي الشامل» جميع الميزات الأساسية لـ $jsonSchema في تعريف مجموعة منتجات كاملة — بما في ذلك التحقق من صحة الأنواع، والتعبيرات النمطية، والتعدادات، والنطاقات، والمستندات المتداخلة، والتحقق من صحة عناصر المصفوفات، وغير ذلك — لإظهار النطاق الكامل للتحقق من صحة المخططات على مستوى الإنتاج.

قائمة مراجعة لتصميم مخطط قاعدة البيانات على مستوى الإنتاج:

// === Create a Product Collection(Includes complete Schema Validation)===
db.createCollection('products', {
  validator: {
    $jsonSchema: {
      bsonType: 'object',
      required: ['sku', 'title', 'price', 'category'],
      properties: {
        sku: {
          bsonType: 'string',
          pattern: '^[A-Z0-9-]+$',
          maxLength: 50
        },
        title: {
          bsonType: 'string',
          minLength: 1,
          maxLength: 200
        },
        price: {
          bsonType: 'decimal'
        },
        category: {
          enum: ['Electronics', 'Books', 'Clothing', 'Home']
        },
        stock: {
          bsonType: 'int',
          minimum: 0
        },
        tags: {
          bsonType: 'array',
          items: { bsonType: 'string' }
        }
      }
    }
  },
  validationLevel: 'moderate',
  validationAction: 'error'
});

الإخراج:

TEXT 📖 للعرض فقط

📋 Copy

الإدراج الناجح: { acknowledged: true, insertedId: ObjectId('...') }
الإدراج الفاشل (بريد إلكتروني غير صالح): Document failed validation
الإدراج الفاشل (اسم المستخدم قصير جدًا): Document failed validation
الإدراج الفاشل (العمر أقل من 18): Document failed validation

▶ مثال: دليل عملي لمُثبت صحة $jsonSchema في MongoDB

// 1. Create a collection with validation rules
db.createCollection('users', {
  validator: {
    $jsonSchema: {
      bsonType: 'object',
      required: ['email', 'username', 'age'],
      properties: {
        email: {
          bsonType: 'string',
          pattern: '^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$',
          maxLength: 100
        },
        username: {
          bsonType: 'string',
          minLength: 3,
          maxLength: 30,
          pattern: '^[a-zA-Z0-9_]+$'
        },
        age: {
          bsonType: 'int',
          minimum: 18,
          maximum: 120
        },
        role: {
          enum: ['customer', 'admin', 'moderator']
        }
      }
    }
  },
  validationLevel: 'moderate',  // Validate only newly inserted records/Update
  validationAction: 'error'     // Reject Illegal Data
});

// 2. Testing Valid Data → Success
db.users.insertOne({
  email: 'alice@example.com',
  username: 'alice_2026',
  age: 28,
  role: 'customer'
});
// { acknowledged: true, insertedId: ObjectId('...') }

// 3. Testing Invalid Data → Rejected
db.users.insertOne({
  email: 'invalid-email',   // Invalid email address
  username: 'ab',            // The username is too short
  age: 15                    // Under 18 years old
});
// Throw an error:Document failed validation
// The error message includes the field name and the reason for the failure.

// 4. Modify the Validator(Add a New Rule)
db.runCommand({
  collMod: 'users',
  validator: {
    $jsonSchema: {
      bsonType: 'object',
      required: ['email', 'username', 'age', 'phone'],
      properties: {
        email: { bsonType: 'string', pattern: '^.+@.+$' },
        username: { bsonType: 'string', minLength: 3 },
        age: { bsonType: 'int', minimum: 18 },
        phone: { bsonType: 'string', pattern: '^\+?[0-9]{10,15}$' }  // New
      }
    }
  }
});

// 5. Nested Document Validation
db.createCollection('orders', {
  validator: {
    $jsonSchema: {
      bsonType: 'object',
      required: ['userId', 'items', 'total'],
      properties: {
        userId: { bsonType: 'objectId' },
        items: {
          bsonType: 'array',
          minItems: 1,
          items: {
            bsonType: 'object',
            required: ['productId', 'qty', 'price'],
            properties: {
              productId: { bsonType: 'objectId' },
              qty: { bsonType: 'int', minimum: 1 },
              price: { bsonType: 'decimal', minimum: 0 }
            }
          }
        },
        total: { bsonType: 'decimal', minimum: 0 }
      }
    }
  }
});

// 6. Turn Off the Verifier(For example, when migrating data)
db.runCommand({
  collMod: 'users',
  validator: {},
  validationLevel: 'off'
});

النتيجة: يتم إدراج البيانات الصحيحة بنجاح؛ بينما تُرفض البيانات غير الصحيحة، ويتم الإبلاغ عن الحقول المحددة التي فشل إدخالها. مستوى التحقق من الصحة: متوسط. يضمن عدم تأثر البيانات الموجودة.

الاستراتيجية التشغيلية للتحقق من صحة المخطط: يتطلب التحقق من صحة المخطط دعماً تشغيلياً في بيئات الإنتاج — 1. استراتيجية النشر: أولاً، قم بتعيين validationAction: 'warn' (التسجيل فقط، دون رفض)، وقم بالمراقبة لمدة أسبوع إلى أسبوعين للتأكد من أن عمليات التحقق تعمل بشكل صحيح، ثم قم بالتبديل إلى error؛ 2. التراجع في حالات الطوارئ: قم بإعداد أمر التراجع (db.runCommand({collMod: 'users', validator: {}, validationLevel: 'off'}) لتعطيل عملية التحقق بسرعة في حالة حدوث نتائج إيجابية خاطئة؛ 3. ترحيل البيانات: قم بتعطيل التحقق من الصحة (validationLevel: 'off') قبل تشغيل نصوص الترحيل البرمجية، ثم أعد تفعيله بعد الترحيل؛ 4. المراقبة والتنبيهات: راقب أحداث «فشل التحقق من الصحة» في سجلات MongoDB؛ فالفشل المتكرر يشير إلى أن قواعد التحقق من الصحة تحتاج إلى تعديل؛ 5. التحكم في الإصدارات: قم بتخزين تعريف $jsonSchema في نظام التحكم في الإصدارات (ملف JSON + نص برمجي للنشر) وقم بإصداره بالتزامن مع كود التطبيق.

مسار آمن لتطوير قواعد التحقق من صحة البيانات: تنقسم التعديلات على قواعد التحقق من صحة المخطط إلى ثلاث فئات — 1. تخفيف القواعد (آمن): إضافة حقول اختيارية، أو زيادة maxLength، أو خفض minimum دون الإخلال بالبيانات الموجودة؛ 2. تشديد القواعد (محفوف بالمخاطر): إضافة حقول إلزامية، أو تضييق نطاق التعداد، أو رفع minimum — قد لا تتوافق البيانات الحالية مع القواعد الجديدة؛ 3. تغييرات النوع (الأكثر خطورة): تغيير bsonType من string إلى int، وما إلى ذلك، مما سيؤدي بشكل شبه مؤكد إلى فشل التحقق من الصحة. مسار التطور الآمن: أولاً، تخفيف القواعد (جعل الحقول الجديدة اختيارية) → استكمال البيانات (استخدام البرامج النصية لملء الحقول الجديدة في المستندات الحالية) → ثم تشديد القواعد (تعيين الحقول الجديدة كحقول إلزامية). اترك فترة تتراوح بين أسبوع وأسبوعين بين كل خطوة لضمان اتساق البيانات.

❓ أسئلة شائعة

📖 ملخص

• أداة التحقق من صحة $jsonSchema: تحدد بنية المستند
• validationAction: خطأ (رفض) / تحذير (تحذير)
• مستوى التحقق: صارم (البيانات كلها) / معتدل (البيانات الجديدة فقط؛ موصى به)
• مخطط مونغوس مقابل $jsonSchema: متكاملان
• تطور المخطط: إضافة الميزات تدريجيًّا، وتعديل الأنواع بحذر

📝 تمارين

1. السؤال الأساسي (⭐): قم بإنشاء عملية تحقق من صحة $jsonSchema لمجموعة users (البريد الإلكتروني/اسم المستخدم/العمر).
2. السؤال الأساسي (⭐): يختبر الفرق في السلوك بين validationAction: warn وvalidationAction: error.
3. تمرين متقدم (⭐⭐): استخدم collMod لتعديل أداة التحقق من صحة مجموعة موجودة (إضافة حقل جديد).
4. مشكلة متقدمة (⭐⭐): قم بتنفيذ عملية التحقق المزدوجة باستخدام Mongoose و$jsonSchema.
5. سؤال التحدي (⭐⭐⭐): التعريف الكامل لـ $jsonSchema لمجموعة المنتجات (بما في ذلك العناصر المتداخلة، والمصفوفات، و Decimal128).

فريق Web-Tutorial التقني

منصة دروس برمجية يديرها عدة مطورين. كل درس يتم كتابته ومراجعته بواسطة مطورين متخصصين في المجال. نعمل على ضمان دقة وموثوقية المحتوى — إذا لاحظت أي مشكلة، فيرجى إخبارنا.

من نحن