مختبر ترقية IndexedDB مع تبويبات مفتوحة: مشاريع تخرج تطوير الويب

تعمل قاعدة IndexedDB في المتصفح محلياً، وقد يفتح الطالب الصفحة في تبويبين ثم يرفع نسخة جديدة تتطلب إنشاء مخزن أو فهرس. التبويب الأقدم قد يظل متصلاً بالقاعدة ويؤخر فتح الإصدار الجديد. مشروع تخرج لتطوير الويب يمكن أن يجعل هذه الحالة مرئية: تبويب يمثل الإصدار 1، وآخر يحاول فتح الإصدار 2، ولوحة تعرض إشعاري versionchange وblocked وما فعله كل طرف. الموضوع عن تنسيق ترقية قاعدة محلية بين عملاء مفتوحين؛ ليس مزامنة بيانات بين أجهزة أو استيراد ملف دفعي.

هذا نطاق مناسب لمشاريع تخرج تطوير الويب التي تحتاج اختبار تحديث مخطط محلي مع الحفاظ على بيانات تجريبية.

خطط المخطط كإصدارات متعاقبة

تعرّف مواصفة Indexed Database API 3.0 قاعدة ذات إصدار، وتنفذ تغييرات المخطط في معاملة الترقية عند فتح إصدار أحدث. ابدأ بمخزن notes ثم أضف فهرساً أو مخزناً جديداً في الإصدار التالي. لا تحذف كل البيانات لتجاوز مشكلة الترقية؛ سجل تغيير المخطط بدقة واجعل انتقال النسخة قابلاً للاختبار. ضع صفحة تعرض رقم الإصدار الحالي وما إذا كان الاتصال مفتوحاً.

في كل تبويب، أضف رقم بناء مرئياً مثل «العميل القديم» و«العميل الجديد». عندما يتلقى اتصال قاعدة البيانات الحدث الذي يشير إلى أن إصداراً أعلى يطلب الفتح، يمكن للتبويب أن يحفظ عمله ويغلق الاتصال. يوضح MDN حدث versionchange كيف يعرف الاتصال الحالي أن إصدار قاعدة البيانات سيتغير. لا تعتمد على أن المستخدم سيغلق الصفحة دائماً؛ أظهر رسالة عملية تشرح أن التحديث ينتظر تبويباً آخر.

افهم لماذا يظهر blocked

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

افصل بين حالتين: الإصدار الجديد ينتظر اتصالاً قديماً، والترقية نفسها فشلت بسبب خطأ في كود migration. الأولى تظهر عندما لا تغلق الاتصالات السابقة، والثانية قد تُرجع خطأ أثناء إنشاء المخزن أو الفهرس. سجل الحدث والاسم والنسخة والنتيجة؛ لا تعرض «تعذر التحديث» فقط، لأن المطور يحتاج لمعرفة أي مسار فشل.

اكتب ترقيات صغيرة قابلة لإعادة التشغيل

أنشئ خطوة من v1 إلى v2، ثم خطوة مستقلة من v2 إلى v3. عند ترقية مستخدم من v1 مباشرة إلى v3، يجب تنفيذ التغييرين بالترتيب في معاملة الترقية الحالية. اختبر بيانات فارغة وبيانات موجودة وصفوفاً لا تملك الخاصية الجديدة. لا تنفذ عمليات شبكة داخل ترقية المخطط؛ اجعل التغيير محلياً وحتمياً حتى يمكن تقييم نجاحه أو فشله.

احتفظ بنسخة من قاعدة اختبار اصطناعية لكل إصدار، واستخدم زر إعادة ضبط واضحاً يحذف بيانات المختبر فقط. افصل reset عن زر إعادة المحاولة حتى لا يمحو الطالب البيانات من دون قصد. إذا تعطلت خطوة، اترك الاختبار يعرض الخطأ ولا تحاول تحويله إلى قاعدة فارغة تلقائياً.

مثال تبويبين وترقية متوقفة

افتح صفحة المختبر في نافذتين. الأولى تفتح قاعدة باسم campus-demo بالإصدار 1 وتبقي الاتصال مفتوحاً. الثانية تطلب الإصدار 2 الذي يضيف فهرساً على updatedAt. يجب أن تظهر في النافذة الجديدة حالة انتظار، وفي القديمة حدث versionchange ثم رسالة «التحديث جاهز؛ احفظ وأغلق». بعد إغلاق الاتصال، تكمل الثانية الترقية وتعرض عدد السجلات قبلها وبعدها. الأسماء والبيانات هنا اصطناعية وليست سجلاً جامعياً.

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

مصفوفة الاختبار والفشل

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

أعد تحميل التبويب القديم بعد اكتمال الترقية وتأكد أنه يستطيع فتح المخطط الحديث أو يعرض طريقة تحديث مفهومة. احذف التخزين التجريبي وكرر الاختبار لعزل أثر cache. اختلاف سلوك المطورين قد ينتج من إصدارات المتصفح وسياسات التخزين؛ سجل البيئة، ولا تدع أن كل الأجهزة تتصرف بالسرعة نفسها.

حدود الفكرة وما يسلمه الفريق

قاعدة المتصفح ليست مخزناً مضمون البقاء إلى الأبد؛ قد يخضع التخزين لحصص وسياسات المتصفح أو يمسحه المستخدم. المختبر لا يحل مزامنة البيانات مع الخادم ولا تعارض تعديل السجل نفسه بين جهازين. أظهر هذه الحدود في التقرير كي لا يفهم المشرف أن ترقية IndexedDB تعادل ترقية قاعدة مركزية.

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