كيفية ترقية وحدات أودو المخصصة إلى أودو 20

ترقية وحدة أودو مخصصة إلى أودو 20 لا تعني تغيير رقم الإصدار في __manifest__.py إلى أن تُثبَّت الوحدة.

لترحيل الوحدة ترحيلًا موثوقًا هدفان منفصلان:

1. جعل الشيفرة المصدرية متوافقة مع أودو 20؛
2. الحفاظ على البيانات التاريخية للعميل وسلوك الأعمال الذي أنشأته الوحدة القديمة.

لذلك فإن سير العمل الأكثر أمانًا هو:

التدقيق ← توافق نظيف مع أودو 20 ← سكربتات ترحيل البيانات ← الاختبار على قاعدة بيانات مُرقّاة ← اختبارات الانحدار للأعمال ← التجربة ← الإنتاج.

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

يركّز هذا الدليل على الوحدة نفسها.

ملاحظة للمطوّرين: الأمثلة أدناه توضّح أنماط الترحيل. تحقّق من كل واجهة برمجية ودالة مساعدة مقابل التوثيق الحالي لأودو 20، واختبرها على قاعدة بيانات مؤقتة قبل استخدامها على بيانات العملاء.

1. ابدأ بتحديد ما إذا كان ينبغي أن تبقى الوحدة أصلًا

قبل نقل الشيفرة، ناقش جدوى التخصيص نفسه.

اسأل:

• ما متطلب الأعمال الذي تحلّه هذه الوحدة؟
• هل ما زال هذا المتطلب قائمًا؟
• هل يحلّه أودو 20 الآن بشكل أصلي؟
• هل يمكن أن تحلّ محلّه الإعدادات أو Studio؟
• هل هناك وحدة مخصصة أخرى تكرّر السلوك نفسه؟
• هل ما زالت تكلفة الصيانة تبرّر هذا التخصيص؟

هذه ليست مسألة إدارة مشاريع فحسب.

كثيرًا ما يكون حذف 2,000 سطر من التخصيصات المتقادمة ترحيلًا إلى أودو 20 أفضل من النجاح في نقل الأسطر الـ 2,000 كلها.

أنشئ جردًا للوحدات مثل:

لا ترحّل إلا ما زال يحقق قيمة.

2. أنشئ فرعًا للترحيل وجمّد خط الأساس

ابدأ من مراجعة الإنتاج بالضبط.

من الأساليب العملية في Git:

git checkout <production-branch>
git pull
git checkout -b migration/20.0

استراتيجية الفروع بالتحديد متروكة لك، لكن المتطلب المهم هو إمكانية التتبّع.

يجب أن تعرف:

• أي إيداع (commit) من أودو 19 يعمل حاليًا في الإنتاج؛
• أي إيداع يبدأ ترحيل أودو 20؛
• ما الإصلاحات التي أُضيفت بعد التجميد؛
• أي إيداع استُخدم في كل تجربة ترحيل.

تجنّب ترحيل هدف متحرك.

3. حدّث بنية الوحدة عن قصد

ابدأ بـ __manifest__.py.

راجع:

• الإصدار؛
• الاعتماديات؛
• ملفات البيانات؛
• البيانات التجريبية؛
• الأصول (assets)؛
• الاعتماديات الخارجية؛
• خطافات التثبيت (install hooks)؛
• أعلام التطبيق.

لا تكتفِ بتغيير:

"version": "19.0.1.0.0"

إلى:

"version": "20.0.1.0.0"

ثم تعتبر الوحدة مُرحَّلة.

يجب أن يتم تغيير ملف البيان (manifest) جنبًا إلى جنب مع مراجعة الاعتماديات.

إذا كانت الوحدة تعتمد على وحدة قياسية انتقلت مسؤوليتها أو تغيّرت في أودو 20، فقد يؤثر ذلك في كل ما يعتمد عليها.

4. استخدم أدوات أودو لترقية الشيفرة كمُسرِّع لا كحلّ نهائي

يتضمن توثيق المطوّرين الحالي لأودو أداة سطر أوامر upgrade_code لإعادة كتابة الشيفرة المصدرية بأفضل جهد ممكن.

غرضها التعامل مع جزء من أعمال النقل المتكررة عبر ملفات الشيفرة المصدرية.

ومن الأنماط الموثّقة:

odoo-bin upgrade_code \
  --from 19.0 \
  --to 20.0 \
  --addons-path=/path/to/custom/addons \
  --dry-run

ابدأ بـ --dry-run.

راجع ما يقترحه أودو قبل السماح بإعادة الكتابة الآلية.

ويحذّر أودو صراحةً من أن هذه السكربتات تعمل بأفضل جهد ممكن وليست حلولًا سحرية.

بعد أي إعادة كتابة آلية:

• راجع الفروقات (diff)؛
• شغّل فحوص التدقيق والتحليل الثابت؛
• ثبّت الوحدة على أودو 20 نظيف؛
• شغّل الاختبارات؛
• افحص التحذيرات؛
• راجع يدويًا الشيفرة الحساسة للأعمال.

لا يمكن لتحويل آلي للشيفرة المصدرية أن يعرف ما إذا كان سير العمل المخصص لديك ما زال صحيحًا.

5. ابحث عن تغييرات إطار العمل المعروفة في أودو 20

سجلّ تغييرات ORM الرسمي من أوائل الأماكن التي يجب مراجعتها قبل تصحيح الأخطاء وحدةً وحدة.

تتضمن مدخلات أودو 20 الحالية:

• إزالة Model._table_query؛
• BinaryValue.filename وتغيّر تمثيل الحقول الثنائية عبر RPC؛
• تبسيط التعامل مع الترجمات؛
• سكربت populate جديد لتوليد بيانات الاختبار؛
• تغييرات في تخزين مصطلحات ترجمة ملف البيان.

استخدم هذه التغييرات لإنشاء عمليات بحث في المستودع.

على سبيل المثال، ابحث عن _table_query في الإضافات المخصصة:

grep -R "_table_query" /path/to/custom/addons

إذا كان نموذج مخصص للتقارير أو مبني على SQL يعتمد عليه، فتعامل مع ذلك كمهمة ترحيل صريحة.

وافعل الشيء نفسه مع أي واجهة برمجية موثّقة تستخدمها وحداتك.

6. راجع شيفرة ORM بلغة Python

افحص في كل نموذج ما هو أبعد من صحة الصياغة.

راجع:

• create()؛
• write()؛
• unlink()؛
• الحقول المحسوبة؛
• الدوال العكسية (inverse)؛
• القيود؛
• سلوك onchange؛
• المنطق المعتمد على الشركة؛
• الافتراضات حول مجموعات السجلات (recordsets)؛
• استخدام السياق (context)؛
• استخدام sudo()؛
• SQL المباشر؛
• الاستيراد من وحدات داخلية أو خاصة.

قد تعمل الدالة دون استثناءات وتبقى خاطئة رغم ذلك.

مثال: دلالات الأعمال مهمة

لنفترض أن تخصيصًا في أودو 19 يعيد تعريف write() لمزامنة حقل مع نموذج آخر.

بعد الترحيل، اسأل:

• هل ما زال الحقل المستهدف يحمل المعنى نفسه؟
• هل ما زالت المزامنة ضرورية؟
• هل أصبح أودو 20 القياسي ينفّذ سلوكًا مرتبطًا بها؟
• هل يمكن أن تتسبب إعادة التعريف في تكرار العمل؟
• هل تتصرف بشكل صحيح عند الكتابة على عدة سجلات دفعة واحدة؟

مراجعة الترحيل فرصة لإزالة عمليات إعادة التعريف الهشّة بدلًا من نقلها آليًا.

7. راجع النماذج المبنية على SQL ونماذج التقارير بعناية

إذا كانت وحدتك تنشئ نماذج _auto = False أو طرق عرض SQL مخصصة أو نماذج تقارير، فخصّص لها قائمة تحقق خاصة بالترحيل.

يزيل أودو 20 Model._table_query.

وهذا يعني أن أي وحدة تعتمد على هذه الآلية تحتاج إلى إعادة تصميم باستخدام النهج المدعوم في أودو 20.

تحقّق أيضًا من:

• دورة حياة إنشاء الجداول وطرق العرض؛
• الأسماء المستعارة في SQL؛
• أنواع الحقول؛
• عمليات الربط (joins)؛
• مرشّحات الشركة؛
• العملات؛
• التجميع؛
• قواعد الوصول؛
• إجماليات التقارير.

قد يُعرض تقرير بنجاح ويعيد مع ذلك أرقامًا خاطئة بشكل يصعب ملاحظته.

8. راجع واجهات XML وتعبيرات XPath الموروثة

وراثة الواجهات من أكثر نقاط فشل الترحيل شيوعًا.

افحص كل واجهة موروثة من حيث:

• معرّف XML للواجهة الأم؛
• الحقول التي نُقلت أو اختفت؛
• أهداف XPath؛
• المجموعات؛
• المُعدِّلات (modifiers)؛
• الإجراءات؛
• الأزرار؛
• كتل الإعدادات؛
• بنية القائمة والنموذج والبحث وkanban.

تعبير XPath هشّ مثل:

<xpath expr="//div[3]/div[2]" position="inside">

ربما عمل لسنوات لأن البنية الأصلية بقيت مستقرة.

فضّل قدر الإمكان المحدِّدات المرتبطة بحقول أو أسماء ذات معنى أو بسمات مستقرة.

لا تُعِد تفعيل كل واجهة معطّلة تلقائيًا

أثناء الترقية القياسية، قد تُعطَّل الواجهات المخصصة التي تسبب مشكلات.

راجع تقرير الترقية (Upgrade Report) واسأل ما إذا كان يجب فعلًا أن تعود الواجهة.

إذا كان أودو 20 يوفّر الآن سير العمل المطلوب بشكل أصلي، فقد يكون حذف الواجهة الموروثة القديمة هو الترحيل الصحيح.

9. راجع JavaScript وOwl وحزم الأصول

نجاح الواجهة الخلفية لا يثبت توافق الواجهة الأمامية.

بالنسبة إلى الوحدات التي تخصّص عميل الويب أو نقاط البيع أو الموقع الإلكتروني أو البوابة، راجع:

• عمليات الاستيراد؛
• السجلات (registries)؛
• الخدمات؛
• الرقع (patches)؛
• مكوّنات Owl؛
• القوالب؛
• حزم الأصول؛
• استدعاءات RPC؛
• أحداث المتصفح؛
• الأدوات والمتحكّمات العامة حيثما ينطبق ذلك.

ثم افحص وحدة تحكم المتصفح أثناء الاختبار.

قد يبدو الترحيل صحيحًا لمطوّر الواجهة الخلفية، بينما يعطّل خطأ JavaScript بصمت أحد مسارات عمل المستخدمين.

10. راجع المتحكّمات وعقود التكامل

المتحكّمات المخصصة عقود مع برمجيات أخرى.

اجرد:

• المسارات (routes)؛
• المصادقة؛
• شكل الطلب والاستجابة؛
• الحمولات الثنائية؛
• رموز الأخطاء؛
• سلوك CORS والأمان؛
• مفاتيح API والرموز (tokens)؛
• عملاء الجوال؛
• خطافات الويب (webhooks).

يغيّر سجلّ تغييرات ORM في أودو 20 تمثيل الحقول الثنائية عبر RPC، لذا تستحق التكاملات الكثيفة المستندات اختبارات انحدار صريحة.

لا تفترض أن العميل الخارجي آمن لمجرد أن وحدة Python تُثبَّت.

11. راجع الأمان كمهمة من مهام الترحيل

اختبارات الانحدار الأمنية مكانها بجانب اختبارات الانحدار الوظيفية.

اختبر:

• ir.model.access.csv؛
• قواعد السجلات؛
• المجموعات والمجموعات الضمنية؛
• حدود الشركات؛
• مستخدمي البوابة والمستخدمين العامين؛
• مسارات sudo()؛
• إجراءات الخادم؛
• مستخدمي API.

أنشئ مستخدمي اختبار يمثّلون الأدوار الرئيسية.

الترحيل الذي يكشف سجلات شركة أخرى أخطر من تخطيط صفحة معطوب.

12. افصل ترحيل الشيفرة عن ترحيل البيانات

هذا التمييز بالغ الأهمية.

لنفترض أن لديك في أودو 19:

legacy_code = fields.Char()

وأن وحدة أودو 20 تعيد تصميمه هكذا:

reference_code = fields.Char()

تغيير اسم الحقل في Python لا يرحّل بأمان المراجع التاريخية بمفرده.

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

13. استخدم سكربتات الترقية لتغييرات البيانات التاريخية

سكربتات الترقية في أودو ملفات Python تحتوي على الدالة migrate(cr, version).

يدعم التوثيق الحالي المراحل pre وpost وend ضمن بنية مثل:

your_module/
└── upgrades/
    └── 20.0.2.0/
        ├── pre-10-rename.py
        ├── post-10-fill-data.py
        └── end-10-cleanup.py

اسم المجلد upgrades مدعوم ومفضّل في التوثيق الحالي، لأن كلمة "migration" قد تُفهم على أنها الانتقال بعيدًا عن أودو.

مرحلة pre

تعمل قبل تحميل الوحدة.

مفيدة للعمليات البنيوية التي يجب أن تتم قبل تطبيق تعريف النموذج الجديد.

مرحلة post

تعمل بعد تحميل الوحدة واعتمادياتها أو تحديثها.

مفيدة عندما تحتاج إلى المخطط الجديد أو ORM الجديد.

مرحلة end

تعمل بعد تحميل جميع الوحدات لذلك الإصدار وتحديثها.

مفيدة للأعمال التي تتطلب السجلّ (registry) أو الحالة النهائية بعد الترقية.

اختر المرحلة بناءً على الاعتماديات، لا على التفضيل الشخصي.

14. فضّل Upgrade Utils لإعادة التسمية مع مراعاة المراجع

وُجدت Upgrade Utils في أودو لأن الأسماء التقنية قد يُشار إليها في أماكن كثيرة.

لإعادة تسمية حقل، تبدو الدالة المساعدة الموثّقة من حيث المفهوم كالتالي:

from odoo.upgrade import util

def migrate(cr, version):
    util.rename_field(
        cr,
        "your.model",
        "legacy_code",
        "reference_code",
    )

يمكن لـ rename_field() تحديث المراجع إلى ما هو أبعد من العمود الفعلي، بما في ذلك عناصر مثل المرشّحات وعمليات التصدير وإجراءات الخادم والحقول المرتبطة والنطاقات (domains).

وهذا أكثر أمانًا من التفكير فقط بمنطق:

ALTER TABLE ...

ومن الأنماط المفيدة الأخرى:

util.rename_model(cr, "old.model", "new.model")

و:

util.rename_xmlid(
    cr,
    "your_module.old_identifier",
    "your_module.new_identifier",
)

تحقّق من التواقيع الحالية الدقيقة قبل النشر أو تشغيل الشيفرة في الإنتاج.

15. تعامل مع بيانات noupdate بشكل صريح

من المفاجآت المتكررة في الترحيل الإعدادات المخزّنة في XML مع noupdate.

تغيير ملف XML لا يعني بالضرورة تحديث السجل الموجود في قاعدة البيانات أثناء التحديث العادي للوحدة.

تتضمن Upgrade Utils في أودو الدالة update_record_from_xml() لتحديث سجل عن قصد من تعريفه في XML.

ويشير التوثيق الحالي إلى أن هذه الدالة المساعدة تستخدم ORM، ولذلك مكانها في مرحلة تكون فيها النماذج المشار إليها محمّلة، وعادةً post أو end.

قد يهمّ ذلك في:

• الإجراءات المجدولة؛
• إجراءات الخادم؛
• القوالب؛
• التسلسلات؛
• القواعد؛
• سجلات الإعدادات.

لا تفرض تحديث كل سجل noupdate. حدّد السجلات التي تحتاج فعلًا إلى التعريف الجديد.

16. اجعل الوحدة تُثبَّت على قاعدة بيانات أودو 20 نظيفة

قبل اختبار بيانات العميل:

1. أنشئ قاعدة بيانات أودو 20 نظيفة؛
2. ثبّت الاعتماديات؛
3. ثبّت الوحدة المخصصة؛
4. أصلح الأخطاء والتحذيرات؛
5. شغّل الاختبارات الآلية؛
6. نفّذ مسارات عمل تمثيلية.

يفصل هذا بين توافق الشيفرة المصدرية وترحيل البيانات التاريخية.

إذا لم تعمل الوحدة على أودو 20 نظيف، فلن تؤدي قاعدة بيانات العميل المُرقّاة إلا إلى جعل تصحيح الأخطاء أصعب.

17. ثم اختبرها على قاعدة بيانات العميل المُرقّاة

بعد أن يستقر التوافق مع الإصدار المستهدف النظيف، اجمع الوحدة مع قاعدة بيانات عميل مُرقّاة تجريبيًا.

ابحث الآن عن المشكلات الخاصة بالبيانات:

• القيم المفقودة؛
• الحقول التي أُعيدت تسميتها؛
• قيم الاختيار القديمة؛
• معرّفات XML المعطوبة؛
• السجلات المكررة؛
• الواجهات المعطّلة؛
• النطاقات غير الصالحة؛
• الإعدادات القديمة؛
• السجلات المؤرشفة؛
• عدم الاتساق بين الشركات المتعددة؛
• المراجع اليتيمة.

هنا يتبيّن ما إذا كانت سكربتات الترقية صحيحة.

18. اختبر الوحدة بحسب أثرها على الأعمال

لا تتوقف عند "نجاح جميع الاختبارات".

اربط كل تخصيص بالنتيجة التي يُفترض أن يحققها.

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

19. أضِف اختبارات آلية خاصة بالترحيل

الاختبارات الوظيفية الحالية مفيدة، لكن الترحيل يجلب أنماط فشل جديدة.

أضِف اختبارات مثل:

• بقاء قيم الحقول القديمة بعد إعادة التسمية؛
• إمكانية الوصول إلى معرّفات XML التي أُعيدت تسميتها؛
• احتفاظ السجلات التاريخية بملكية الشركة؛
• بقاء حالات سير العمل القديمة صالحة؛
• وصول إعدادات noupdate إلى الحالة المستهدفة المقصودة؛
• استمرار الأمان في منع الوصول بين الشركات؛
• تطابق التقارير مع بيانات مرجعية معروفة؛
• حفاظ التكاملات على دلالات الحمولة المتوقعة.

الهدف هو جعل الترحيل قابلًا للتكرار، لا معتمدًا على مطوّر واحد يتذكر كل فحص يدوي.

20. استخدم بيانات اختبار مولَّدة حيث تفيد

يقدّم سجلّ تغييرات ORM في أودو 20 سكربت populate جديدًا لبيانات الاختبار الوهمية.

بالنسبة إلى الوحدات الحساسة للأداء، يمكن أن تساعد البيانات المولَّدة في اختبار:

• أداء البحث؛
• الحقول المحسوبة؛
• العمليات الدفعية؛
• التقارير؛
• المهام المجدولة (cron)؛
• واجهات القوائم؛
• مجموعات السجلات الكبيرة.

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

البيانات المولَّدة لا تُغني عن اختبار قبول المستخدم (UAT) على بيانات مُرقّاة مشابهة للإنتاج، لكنها تحسّن التغطية الهندسية.

21. أجرِ تجربة ترقية الوحدة على نسخة جديدة من قاعدة البيانات

لا تستخدم قاعدة البيانات نفسها التي ظل المطوّرون يصلحونها يدويًا لأسابيع دليلًا على أن الإنتاج سيعمل.

خذ نسخة جديدة من قاعدة البيانات المصدر أو من الترقية التجريبية وكرّر:

1. نشر شيفرة أودو 20 المختبَرة؛
2. تحديث الوحدة؛
3. تشغيل سكربتات الترقية pre/post/end؛
4. فحص السجلات (logs)؛
5. تشغيل الاختبارات الآلية؛
6. تشغيل اختبارات الدخان التقنية؛
7. تشغيل اختبارات أعمال تمثيلية.

سجّل كل أمر يدوي.

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

22. اجعل سكربتات الترقية متساوية القوى (idempotent) حيثما أمكن عمليًا

تصبح عملية الترقية أسهل في تصحيح الأخطاء عندما يمكن تكرار التجربة الفاشلة بشكل متوقَّع.

حيثما أمكن عمليًا:

• تحقّق من وجود الكائن أو القيمة القديمة قبل إعادة التسمية؛
• تجنّب إنشاء سجلات مكررة؛
• سجّل عدد الصفوف المتأثرة؛
• اجعل الفشل صريحًا وواضحًا عند الحالات المستحيلة؛
• تجنّب التحديثات الواسعة غير المقيّدة دون تحقق؛
• أجّل التنظيف الهدّام إلى المرحلة المناسبة.

لا تبالغ في هندسة كل سكربت يُستخدم مرة واحدة، لكن صمّم من أجل تجارب آمنة.

23. راجع السجلات والتحذيرات، لا الاستثناءات فقط

قد تُثبَّت الوحدة مع تحذيرات تشير إلى مشكلات مستقبلية.

راجع:

• تحذيرات الإهمال (deprecation)؛
• الحقول والواجهات المفقودة؛
• تحذيرات الوصول؛
• الأصول التي فشل تحميلها؛
• مشكلات الترجمة؛
• أخطاء إجراءات الخادم؛
• إخفاقات المهام المجدولة؛
• أخطاء وحدة تحكم المتصفح.

اجعل السجلّ الخالي من التحذيرات هدفًا هندسيًا.

24. قائمة التحقق لنشر الإنتاج

قبل ترقية الوحدة في الإنتاج:

الشيفرة

• تمت مراجعة فرع الترحيل.
• تمت مراجعة فروقات إعادة الكتابة الآلية إذا استُخدم upgrade_code.
• الوحدة تُثبَّت على أودو 20 نظيف.
• الاختبارات ناجحة.
• لا توجد تحذيرات حرجة غير محلولة.
• اكتملت المراجعة الأمنية.

البيانات

• رُبطت جميع النماذج والحقول ومعرّفات XML التي أُعيدت تسميتها.
• اختُبرت سكربتات الترقية انطلاقًا من قاعدة بيانات جديدة.
• تمت مراجعة سجلات noupdate.
• تمت مراجعة الواجهات المعطّلة.
• تم التحقق من السجلات التاريخية.

الواجهة الأمامية والتكاملات

• اختُبرت الواجهات بحسب الدور.
• فُحصت JS وOwl ووحدة تحكم المتصفح.
• تم التحقق من التقارير.
• اختُبرت واجهات API والمتحكّمات.
• اختُبرت مسارات العمل الثنائية والمستندات.

التجربة

• اكتملت تجربة على نسخة جديدة.
• قِيس زمن التنفيذ.
• وُثّقت الخطوات اليدوية.
• حُدّدت اختبارات الدخان.
• وافق مالك الأعمال على اختبار قبول المستخدم.

أخطاء شائعة عند ترقية وحدات أودو المخصصة

الاكتفاء بتغيير إصدار ملف البيان

هذا يغيّر البيانات الوصفية، لا التوافق.

إصلاح الأخطاء مباشرةً على قاعدة البيانات المُرقّاة

أصلح الشيفرة المصدرية واكتب سكربتات ترقية حتى يمكن تكرار العملية.

استخدام SQL لكل عملية إعادة تسمية

قد تكون لعمود في قاعدة البيانات مراجع في أماكن أخرى من أودو. استخدم Upgrade Utils التي تراعي المراجع عند الاقتضاء.

وضع كل السكربتات في post

لأودو مراحل pre وpost وend لسبب وجيه. اختر بناءً على توقيت توفّر المخطط القديم أو الجديد والسجلّ (registry).

تجاهل noupdate

تغيّر ملف XML المصدري لا يضمن تغيّر السجل التاريخي في قاعدة البيانات.

الثقة العمياء في إعادة كتابة الشيفرة آليًا

upgrade_code يعمل بأفضل جهد ممكن. راجع كل فرق ذي معنى.

اختبار السجلات الجديدة فقط

الأخطاء الصعبة تكمن عادةً في البيانات التاريخية.

نسيان الواجهة الأمامية والتكاملات

نجاح Python لا يثبت أن Owl أو نقاط البيع أو تطبيقات الجوال أو عملاء API ما زالت تعمل.

ترحيل شيفرة جعلها أودو 20 غير ضرورية

احذف الدين التقني متى استطعت.

الأسئلة الشائعة

هل يستطيع أودو ترقية وحدة مخصصة إلى الإصدار 20 تلقائيًا؟

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

أين يجب وضع سكربتات الترقية في أودو؟

يدعم توثيق أودو الحالي وضع سكربتات ترقية الوحدة تحت migrations/$version/ وكذلك تحت upgrades/$version/، مع وصف upgrades بأنها التسمية المفضّلة. وتستخدم السكربتات البادئات pre- أو post- أو end- في أسماء الملفات لتحديد مرحلة التنفيذ.

متى تعمل سكربتات الترقية؟

تعمل عند تحديث الوحدة، وفقًا لقواعد مجلدات الوحدة والإصدار الموثّقة لدى أودو. تعمل مرحلة pre قبل تحميل الوحدة، ومرحلة post بعد تحميل الوحدة واعتمادياتها وتحديثها، ومرحلة end بعد تحميل جميع الوحدات لذلك الإصدار.

كيف أعيد تسمية حقل مخصص دون فقدان البيانات؟

استخدم سكربت ترقية، وفكّر في الدالة المساعدة rename_field() من Upgrade Utils في أودو، المصمّمة لتحديث الحقل والمراجع المرتبطة به. تحقّق من توقيعها الحالي واختبر الترحيل على قاعدة بيانات مؤقتة أولًا.

هل أختبر على قاعدة بيانات أودو 20 نظيفة أم على قاعدة بيانات العميل المُرقّاة؟

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

الخلاصة

لا يُقاس نجاح ترحيل وحدة مخصصة إلى أودو 20 بسرعة تثبيت الوحدة.

بل يُقاس بما إذا كانت:

• الشيفرة المصدرية تستخدم أنماط أودو 20 المدعومة؛
• البيانات التاريخية تبقى عن قصد؛
• المراجع والإعدادات تظل متسقة؛
• الصلاحيات الأمنية تبقى صحيحة؛
• الواجهة الأمامية والتكاملات ما زالت تعمل؛
• نتيجة الأعمال تبقى كما هي أو تتحسن؛
• عملية الترحيل بأكملها قابلة للتكرار انطلاقًا من قاعدة بيانات جديدة دون إصلاحات غير موثّقة.

وأنفع طريقة تفكير في الترحيل هي:

أتمِت التغييرات الروتينية، وهندِس التغييرات الدلالية، واختبر نتيجة الأعمال.

هل تخطط لمشروع على أودو 20؟ تساعد Octivex Tech الشركات في ترقيات أودو، وترحيل الوحدات المخصصة، والتكاملات، وسير العمل المدعوم بالذكاء الاصطناعي. تصفّح خدماتنا في أودو أو تواصل مع فريقنا الهندسي لمناقشة بيئتك.