المشكلة الحقيقية في الاستيراد الجماعي
استيراد 500 بروفايل ليس مجرد نسخ 500 مجلد. لكل بروفايل معرف إداري ومسار تخزين وإعدادات شبكة ومالك وربما بيانات جلسة مرتبطة بالجهاز. قد تنتهي العملية برسالة نجاح بينما يشير سجلان إلى المجلد نفسه، أو يتكرر معرف داخلي، أو تُربط كوكيز حساب ببطاقة أخرى. يجب تحديد معنى النجاح قبل التنفيذ: عدد السجلات الفريدة، وسلامة العلاقة بين المصدر والوجهة، وقدرة النظام على الاستئناف دون ازدواج، ونجاح اختبار عزل انتقائي بعد النقل.
صمم خريطة معرفات لا تعتمد على الاسم
أنشئ جدولًا يضم source_profile_id و target_profile_id و batch_id و storage_path و owner و status. لا تستخدم اسم العرض مفتاحًا فريدًا؛ قد يمتلك فريق عشرات البروفايلات باسم «عمل» أو «تجربة». إذا لم يقدم المصدر معرفًا ثابتًا، أنشئ مفتاحًا مرتبطًا بملف التصدير ورقم السجل واحفظ قاعدة اشتقاقه. يجب أن يبقى مفتاح الاستيراد ثابتًا عند إعادة المحاولة، وألا يُنشأ معرف وجهة جديد لسجل سبق اعتماده. افصل كذلك معرف الحساب البعيد عن معرف البروفايل المحلي.
جرد المصدر قبل لمس ملفات الوجهة
ابدأ بقراءة ملف التصدير دون كتابة أي شيء. احسب عدد السجلات، والحقول المفقودة، ومعرفات المصدر المكررة، والمجلدات غير الموجودة، والملفات التي لا يمكن قراءتها. دوّن إصدار التطبيق المصدر ومخطط التصدير وحجم الملفات وأي اعتماد على تشفير نظام التشغيل. قارن عدد السجلات بعدد المسارات الفريدة، لأن ملفًا واحدًا قد يشير إلى المجلد نفسه مرتين. أخرج تقرير معاينة يفرق بين سجل صالح وسجل يحتاج قرارًا وسجل لا يمكن نقله. لا تعتبر رسالة «الملف سليم» بديلًا لهذا الجرد.
ميز بين أنواع التكرار
تكرار اسم العرض ليس خطأ بالضرورة، بينما تكرار source_profile_id في دفعة واحدة يتطلب تحقيقًا. تكرار target_profile_id قد يعني محاولة استيراد سابقة يجب استكمالها بدل إنشاء نسخة جديدة. أما تكرار storage_path بين بروفايلين يعملان بالتوازي فقد يسبب تلف قاعدة بيانات التخزين. يمكن استخدام بصمة ملفات للمقارنة، لكن تطابق بصمة قالب نظيف لا يثبت أن البروفايلين يمثلان الهوية نفسها. اعرض سبب الاشتباه للمشغل بدل دمج السجلات تلقائيًا اعتمادًا على تشابه سطحي.
استخدم مفاتيح إعادة المحاولة Idempotency
إذا انقطعت العملية بعد نقل 270 سجلًا، ينبغي أن تستأنف دون إنشاء 270 نسخة إضافية. اربط كل سجل بمفتاح دفعة ثابت، واحتفظ بحالات pending و validated و committed و failed. عند إعادة التشغيل افحص السجل الملتزم وتحقق من وجود ملفاته قبل تجاوزه. لا تعتمد على ترتيب الصفوف وحده؛ قد يتغير ترتيب التصدير. احفظ بصمة الملف المصدر وإصداره، واعتبر تغير المحتوى بين محاولتين حدثًا يستلزم مراجعة لا متابعة صامتة. العملية القابلة للإعادة أكثر قيمة من عملية سريعة يصعب إصلاحها.
انقل الملفات على دفعات مع اعتماد نهائي
قسّم النقل إلى مجموعات صغيرة تناسب مساحة القرص والذاكرة، مثل 20 أو 50 بروفايلًا، دون افتراض أن رقمًا واحدًا يناسب كل جهاز. انسخ البيانات أولًا إلى مسار مؤقت منفصل، وتحقق من الملفات المطلوبة وأحجامها، ثم انقل المجلد إلى اسمه النهائي بعد نجاح الفحص. احفظ نقطة تقدم بعد كل دفعة. راقب نفاد المساحة وأخطاء الأذونات وقفل قواعد البيانات. لا تفتح كل البروفايلات أثناء النسخ، لأن تشغيلها قد يغيّر الملفات أو يقفلها ويجعل النتيجة غير قابلة للتفسير.
تعامل مع الكوكيز والجلسات بواقعية
وجود ملفات Cookies أو Local Storage في النسخة المنقولة لا يضمن بقاء تسجيل الدخول. بعض البيانات مشفرة بمفتاح مرتبط بمستخدم نظام التشغيل، وبعض رموز الجلسة انتهت صلاحيتها لدى الموقع، وبعض التطبيقات تربط الدخول بالجهاز. سجّل هذه الحالات باعتبارها «تحتاج إعادة مصادقة» بدل اعتبار الاستيراد كله فاشلًا أو محاولة تعديل الهوية آليًا. استخدم حسابات اختبار عند التحقق، ولا تنقل بيانات حساسة بين مالكين مختلفين. نجاح نقل إعدادات البروفايل يختلف عن نجاح مصادقة موقع خارجي.
ضع سياسة تعارض صريحة
إذا وجد بروفايل بالمعرف نفسه في الوجهة وله تعديلات أحدث، فلا تستبدله افتراضيًا. الخيارات العملية هي تخطيه، أو إنشاء نسخة مستقلة بمعرف جديد، أو دمج حقول إدارية محددة بعد مراجعة الفروق. لا تدمج ملفات كوكيز أو قواعد بيانات متصفح حية بمجرد جمعها؛ قد تكون بنيتها غير متوافقة. اعرض للمستخدم عدد السجلات التي ستتأثر بكل قرار، واحفظ القرار وتوقيته. يجب أن تكون سياسة التعارض جزءًا من معاينة الدفعة لا سؤالًا مفاجئًا في منتصف العملية.
تحقق من الإعدادات لا عدد البطاقات فقط
بعد النقل قارن الحقول المطلوبة: البروكسي ونوعه، واللغة، والمنطقة الزمنية، ووكيل المستخدم، والوسوم، والمجموعة، والمالك، والأذونات، والامتدادات المدعومة. إذا كان حقل غير قابل للنقل بسبب اختلاف الإصدار، فاذكره صراحة ولا تضع قيمة افتراضية توحي بأنه حُفظ. قارن العدد النهائي للمعرفات الفريدة وعدد مسارات التخزين الفريدة مع التقرير الأولي. أي اختلاف يجب أن يملك سببًا موثقًا، لا أن يختفي داخل نسبة نجاح إجمالية تبدو مرتفعة.
اختبر العزل بعينة متنوعة
اختر بروفايلًا نظيفًا وآخر ذا امتدادات وثالثًا يستخدم بروكسي ورابعًا يملك تخزينًا محليًا كبيرًا. افتح كل واحد على حدة، وتحقق من إعداداته ومن عدم ظهور كوكيز أو بيانات بروفايل آخر. جرّب إغلاقه وإعادة فتحه لأن بعض الأخطاء لا تظهر إلا عند إعادة التشغيل. افحص سجلات المتصفح ورسائل الأذونات، لكن لا تستخدم حسابات العملاء في اختبار غير ضروري. نجاح العينة يؤكد جانبًا من التشغيل؛ أما تفرد المعرفات والمسارات فيجب فحصه على جميع السجلات بلا استثناء.
التراجع يجب ألا يمس البيانات السابقة
افترض أن الدفعة فشلت عند السجل الأخير. يجب أن تعرف بالضبط ما أُنشئ خلال هذه المحاولة وما كان موجودًا قبلها. استخدم batch_id لتمييز الملفات والسجلات الجديدة، واحتفظ بخريطة معرفات ونسخة من حالة الوجهة قبل الكتابة. قد يكون التراجع حذفًا للسجلات الجديدة أو تعطيلًا لها مؤقتًا، حسب السياسة. لا تحذف ملفات مصدر أو بروفايلات سابقة لمجرد تشابه الأسماء. اختبر التراجع على بيانات تجريبية قبل التعامل مع إنتاج فعلي.
مثال عددي لتقرير لا يضلل
لنفترض أن ملف المصدر يحتوي على 500 سجل: 480 صالحًا، و 12 تكرار معرف، و 8 مراجع مفقودة. إذا نُقل 475 من أصل 480، فنجاح التنفيذ نحو 98.96% بين السجلات المقبولة، لكنه 95% من الملف الأصلي. اذكر المقامين بوضوح، ثم اعرض خمسة إخفاقات تنفيذية مع أسبابها وإمكانية إعادة المحاولة. أضف عدد المسارات الفريدة وعدد الجلسات التي تحتاج دخولًا جديدًا. لا تخلط بين نجاح النسخ ونجاح تسجيل الدخول إلى مواقع خارجية.
جدول القرار العملي
قرارات التعامل مع التعارض أثناء الاستيراد
| معرف مصدر مكرر | إيقاف وتسوية | ازدواج هوية |
| اسم عرض مكرر | تنبيه فقط | الاسم غير فريد |
| مسار وجهة مكرر | منع الكتابة | تلف محتمل |
| جلسة مشفرة غير قابلة للنقل | إعادة تسجيل الدخول | ارتباط بالجهاز |
يمكن تلخيص القرار في أربع حالات: تكرار معرف المصدر يستلزم إيقافًا وتسوية؛ تكرار الاسم فقط يستلزم تنبيهًا؛ تكرار مسار الوجهة يستلزم منع الكتابة؛ تعذر نقل جلسة مشفرة يستلزم الاحتفاظ بالإعدادات المسموحة وطلب دخول جديد. إذا نفدت مساحة القرص، أوقف الدفعة مع حفظ نقطة التقدم. يختلف هذا عن فساد ملف المصدر، الذي يستلزم إعادة تصدير أو استبعاد السجل. يجب أن يظهر سبب كل قرار في سجل الاستيراد، لا مجرد رمز خطأ عام.
اختبارات آلية قابلة للإعادة
اصنع ملفًا اصطناعيًا فيه مئة سجل، ثم كرر عشرة معرفات عمدًا، وغيّر ترتيب الصفوف، واقطع العملية في منتصفها. تحقق أن إعادة التشغيل لا تنشئ نسخًا إضافية. اختبر اسمًا عربيًا ومسارًا طويلًا وملفًا مفقودًا وسجلًا يحمل اسم عرض مكررًا بمعرف مختلف. ضع توقعًا مكتوبًا لكل حالة قبل التنفيذ، ثم قارن الناتج بقاعدة البيانات ومجلدات التخزين. الاختبار الجيد لا يكتفي بأن التطبيق لم يتعطل؛ بل يثبت صحة الأثر النهائي.
التوثيق والمراجع
احتفظ بتاريخ التنفيذ وإصداري المصدر والوجهة وبصمة ملف التصدير وخريطة المعرفات وسياسة التعارض والأخطاء المتبقية. لا تسجل كلمات المرور أو محتوى الكوكيز. راجع معاملات SQLite في https://www.sqlite.org/lang_transaction.html، وإرشادات تسجيل الأحداث من OWASP في https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html. ولتوسيع اختبار العزل اقرأ مقال إيجي تاج «ستة فحوص تأسيسية لعزل البروفايلات» على https://egytag.com/ar/articles/profile-isolation-tests-hazem-alaa-2026-10-03. الاستيراد الجيد قابل للتدقيق والتراجع، وليس مجرد نسخ سريع.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…