تحية! كما وعدنا في منشور
سابق حول إعادة التعريف المستند إلى الإصدار - هذا هو الجزء الثاني.
إذن ما الذي نعمل به؟ خادم الإنتاج الرئيسي الخاص بنا هو Oracle 12C ، Enterprise Edition. والأمر المهم هو أن نلاحظ أن هناك عشرات التطبيقات التي تعمل عليها في وقت واحد. لماذا نركز على هذا؟ التكنولوجيا جديدة نسبيًا ، فهي ليست جيدة التشغيل. وسيكون من غير المنطقي نقل بعض الأنظمة الحيوية إليها على الفور. لذلك ، قررنا لأنفسنا أن ننتقل ببطء من الأنظمة الأقل أهمية إلى الأنظمة الأكثر أهمية. وفقًا لذلك ، فإن المشكلة التالية التي نحتاج إلى فهمها هي: كيفية التعامل مع تقنية EBR وكيفية تنظيم التكامل في الموقف عندما يكون لدينا إصدار واحد وأخرى لا. في الإصدار 12 من Oracle ، كما اتضح فيما بعد ، يمكنك إنشاء كائنات غير مقطوعة ، وحزم غير منقوصة ، وتماثيل غير منقوصة في نظام تم إصداره لتنظيم التكامل ذاته.
بالطبع ، يمكننا إنشاء واجهة برمجة تطبيقات غير مقطوعة ومنحها للمخطط غير المنقسم للاستخدام. ولكن ماذا لو تم استخدام واجهة برمجة التطبيقات (API) غير الإفتراضية هذه (أو جزء منها) داخل تطبيقنا ونحن بحاجة إلى إصدارها داخل أنفسنا ، وإعطاء الأشياء غير المنقولة إلى الجانب؟ هذه هي المشكلة التالية التي واجهناها. لقد استخدمنا واجهة برمجة التطبيقات (API) عدة مرات ، ولكن ، كما تتذكر ، هناك قيود على أنه لا يمكن استخدام الكائنات التي تم إصدارها بدون تحويل. بطبيعة الحال ، شريطة أن يتم تشغيل العديد من التطبيقات على الخادم ، كان من الضروري أن نفهم كيف يمكننا تبديل تطبيق واحد إلى الإصدار الجديد والحفاظ على القدرة على استخدام واجهة برمجة التطبيقات لهذا المخطط مع أنظمة قواعد البيانات الأخرى.
هناك العديد من الخيارات لتثبيت الإصدار:
- قم بتعيين قيمة الإصدار الافتراضية إلى قاعدة البيانات بأكملها
- تثبيت البيئة ، مرة أخرى على قاعدة البيانات بأكملها.
يتم رفض هذه الخيارات على الفور لأن بعض التطبيقات على الأقل لن يتم التبديل إلى استخدام EBR.
من الممكن أيضًا إنشاء خدمة لتحديد الإصدار ، أو تحديد الإصدار عند توصيل التطبيق بالدائرة. يعد هذا مناسبًا إذا اتصلنا بقاعدة البيانات من خلال بعض تطبيقات الجهات الخارجية.
وإذا كنا بحاجة إلى وظائف لتشغيلها وفقًا للجدول الزمني والعمل في بعض الإصدارات المحددة؟ وفقًا لذلك ، هناك خيار آخر للتبديل إلى إصدار جديد - وهو
توجيه الجلسة الحالية إلى إصدار محدد .
في الواقع ، لقد اخترنا هذا لأنفسنا كحل. يمكنك إرفاق أحد المشغلات بعد تسجيل الدخول بالنظام الذي تم إصداره ، والذي سيقول إن الجلسة الحالية في هذا المخطط ستعمل في هذا الإصدار.
العودة إلى التكامل وتكرار المنطق. هناك مهام: أريد إصدار نوع من منطق التطبيق داخل المخطط الخاص بي ، وأحتاج أيضًا إلى تعريضه لمستخدم غير إصداري. في البداية ، يبدو أنه لا يمكن تنفيذ ذلك ، ولكن ، عند الخوض في السؤال ، نظرنا إلى أن حزمة dbms_sql المعتادة ، والتي تهدف من حيث المبدأ إلى إجراء نوع من الاستعلامات الديناميكية ، يمكن أن تساعد في حل هذه المشكلة. كيف؟ بسيط للغاية - عند معالجة طلب أو الاتصال بأي كتلة مجهولة المصدر ، يمكننا أن نلقي اسم الشرط كمعلمة ، مما يشير إلى الإصدار الذي سيتم فيه تحليل هذه الشفرة وتنفيذها. إذا كنا بحاجة إلى استخدام بعض الإجراءات داخل أنفسنا وإعطاء نفس الإجراء لمخطط طرف ثالث ، فنحن ببساطة نلفه بمكالمة في إجراء dbms_sql.parse ، وبالتالي ننشئ مجمّعًا يمكن وضعه في كائن ليس به نسخ ، و - من فضلك ، يمكننا استخدام كائن لدينا نسخة مستخدم غير منقسم.
ماذا تواجه هنا؟ لسبب ما ، عند تحديد الشرط ، لا يتم إصدار معاملات الخروج في الإجراءات. لماذا - هذا غير واضح ، ولكن في تلك المخططات التي عملنا عليها ، لا يتم استخدام هذا كثيرًا. ربما سنعيد المنطق بطريقة أو بأخرى ، أو سنبحث عن حلول أخرى.
المشكلات التالية هي الأخطاء أو ميزات EBR التي واجهناها. الأول هو مشكلة في الأنواع المبنية ووظائف خطوط الأنابيب. ما علاقة خط الأنابيب به؟ إلى جانب حقيقة أن لدينا بالفعل بعض الخوارزميات التي تعمل على أساس وظائف خطوط الأنابيب ، Pipeline هو حل معين لوضع وجهة نظر الإصدار إلى الجانب. لقد ورثنا طرق العرض ، التي تحتوي على منطق معقد إلى حد ما لعملية معالجة البيانات ، كما تستخدم مخططات الجهات الخارجية هذه المشاهدات. وفقًا لذلك ، كان من الضروري فهم كيفية تعيين طرق عرض الإصدارات الخاصة بنا على دائرة مستهلكين لبيانات غير متعلقة بالإصدار ، شريطة ألا تتغير مجموعة مخرجات الأعمدة. كحل من هذا النوع ، كان من الواضح أنه يمكنك التفاف كل هذه المشاهدات مع dbms_sql في وظيفة Pipeline ووضعها في العرض النهائي للمستهلك ، نعم ، هذا كثيف الاستخدام للموارد بالنسبة للخادم ، لكن هذا لن يتطلب أي تعديلات من جانب نظام الاستقبال.
لذا ، بالعودة إلى استخدام وظائف خطوط الأنابيب ، اتضح أنه إذا لم يتم إنشاء النوع الذي يتم إنشاؤه في حزمة الإصدار التي يتم إنشاؤها وإنشائها لأول مرة ، فإن الحزمة ببساطة لا يتم تجميعها وتنهارها. على الفور حل لم يأت ، ذهب للبحث عن ما اقترحه زملائه المبرمجين؟ قال أحدهم إنه مطلوب لإنشاء هذا النوع في الإصدار صفر من الحزمة ، أو لإنشاء حزمة مع النوع المقابل في الإصدار صفر من قاعدة البيانات. لم يكن من الواضح سبب القيام بذلك. وجدوا حلًا يمكن ببساطة وضع هذه الأنواع ، التي يتم إنشاؤها ضمنيًا عند تجميع الحزمة ، في نوع منفصل ككائن قاعدة بيانات. وبالتالي ، يتم حل مشكلة وظائف الناقل.
الميزة التالية التي تعثرنا عليها هي السلوك غير القياسي لوجهات النظر التي تم إصدارها.
تذكر ، تحدثت عن حقيقة أن الكائنات موروثة وتحديثها؟ لذلك ، اتضح أنه إذا قمت أنت وأنا بإنشاء طريقة عرض مُصدّرة على إصدار صفري مشروط ، بحلول الإصدار الخامس ، لاحظنا أنه كانت لدينا معلومات غير دقيقة في التعليقات. على سبيل المثال ، لاحظت بنفسي أنه في تعليق على عمود يمكنني مبادلة حرفين في أماكن. لا تترك هذا النقص!
لذلك ، يؤدي أمر التعليقات المعتاد إلى حقيقة أن طريقة عرض الإصدار المحدّث لدينا يتم تحديثها في الإصدار الحالي. وبسبب هذا ، كل الحزم التابعة تنهار ، وكيفية التعامل معها؟ للقيام بذلك ، قاموا بكتابة برنامج نصي معين ، والذي عند إنشاء إصدار جديد ، سيقوم بتحديث عرض الإصدار في كل مرة يتم إصدار الإصدار التالي. لا يحمل هذا عبءًا كبيرًا على قاموس قاعدة البيانات ، ولكن إذا لزم الأمر ، قم بإجراء تصحيحات بسيطة أو ، على سبيل المثال ، إصدار منح جديدة ، لسنا بحاجة إلى إنشاء إصدار جديد
حسنًا ، آخر خطأ أو ميزة من هذا القبيل ... ليس من الواضح لماذا ، عند تغيير لاغية ، فإن القيود المفروضة على عمود طرق العرض التي تم إصدارها قد انفصلت. بمعنى أنه بمجرد أن نقول إن عمودنا في الجدول الأساسي يجب ألا يتضمن قيودًا فارغة ، فإن طريقة العرض تنهار حتى عند استخدام إعادة تعريف dbms. لم نتمكن من هزيمة هذا الشيء بأي شكل من الأشكال ، ربما صادف القراء ذلك ، سيكون من المثير للاهتمام معرفة ما إذا كان قد تم إيجاد حل.
ماذا أود أن أقول في الختام؟ الإصدار المستند إلى الإصدار Redefinition هو تقنية فعالة للحصول على فرصة حقيقية لإصدار إصدار أو إصلاح عاجل عبر الإنترنت ، في وضع المستخدم. لمسنا وشعرنا وأدركنا أن تنظيم التكامل على خادم واحد ، عندما لا تنتقل جميع المخططات لاستخدام هذه التكنولوجيا ، يعد أمرًا حقيقيًا ، ناهيك عن أن المخطط الذي تم إصداره يمكن أن يعمل على خادم مخصص أو على قاعدة بيانات حاوية منفصلة.
وكتطبيق وإجابة على السؤال الرئيسي ، "هل من الممكن في الإنتاج؟" ... نأمل أن ينتقل الإصدار المعتمد على الإصدار عاجلاً أم آجلاً إلى جميع مشاريعنا ، وربما تكون هذه هي المحطة الأخيرة في طلباتنا وتضمن الهدوء نوم المطور المسؤول عن تثبيت الإصدار الجديد.
في الواقع ، هذا كل شيء. شكرا لاهتمامكم