Abdulhakim Mohamed Ahmed على LinkedIn: السلام عليكم ورحمة الله وبركاته دا البوست الثاني في سلسلة EF Core… (2024)

السلام عليكم ورحمة الله وبركاتهالبوست دا تكلمه للبوست السابق اللي اتكلمنا فيه عن مشكلة اللهو الخفيللأهمية راجع الجزء الأول من البوست:https://lnkd.in/d8QctPxFالسيناريو اللي متوقع تحصل فيه المشكلة كالتالي:تخيل ان في Dev3اضاف Migration103 ، هنا ناتج مقارنة ال Current Modelمع ال ModelSnapshotهتكون صحيحة لأن ال ModelSnapshotنفسها صحيحة مفيهاش مشكلة وبالتالي محتويات ال Migration fileهتكون صحيحة، لكن تخيل ان Dev3 وهو بيراجع اكتشف ان ال Migration103اللي اضافه فيه مشكلة وحب يعمل عليه تعديل فاستخدم Remove-Migration هنا هتحصل المشكلة، ليه بقي؟ لأن لما Migration103اتعمل له Remove هيبقي اخر Migration عندنا هو Migration102مش دا اللي قولنا ان ال Snapshotبتاعته مش سليمة؟ ايوة للأسف واللي هيحصل ان EF Core هتاخد ال Snapshot بتاعت ال Migration102 وتعدل بها ال ModelSnapshot وبالتالي كمان ال ModelSnapshot بقت هي كمان مش صحيحة، وبكدا اي Migrationجديد نفترض Migration104 هيواجه مشكلة لما ال EF Core تعمل مقارنة بين ال Current Model وبين ال ModelSnapshotوهتلاقي ال Migration file الجديد بيحاول يضيف FullName وهي اصلا موجودة اتضافت في Migration101المشكلة انه من البدايةMigration102 Snapshot مكانش فيها FullName وعند اضافة Migration104 ال EF Core لقتال FullName في ال Current Modelوملقتهاش في ال ModelSnapshot فاعتبرتأنها جديدةواضافتها للكود الموجود في ال Up method ولو جيت تعمل applyلل Migration104 هيضرب في وشكطب ايه الحل:1-الوقاية خير من العلاج، الأفضل طبعا اننا نعمل commit لكل migration بحيث الmigrationيبقي في commitمنفصلة بحيث لو عملت migration فيه مشكلة وعاوز ارجع فيه فقط هعمل Undo لل pending changes ومستخدمش Remove-Migrationوبالتالي ال gitهتمسح ال Migration file وكمان هترجع ال ModelSnapshot، دا عشان نحمي ال migrationالجديد لكن مازال ال Migration Snapshot الخاصة بال Migration102 في المثال بتاعنا فيها مشكلة2-عشان المشكلة دي متحصلش يا حبذا لو بعد ال ما gitمشكورة علمت Merge اننا ناخد copyمن ال ModelSnapshot ونعدل بها ال Migration Snapshot بتاعت اخر Migration3-من الجيد انك تعمل unit test تتأكد ان ال ModelSnapshotواخر Migration Snapshotيكونوا زي بعض ودايما تعمل run لل unit test دي قبل اضافة اي Migration4-الحل الصعب انه نعمل Remove-Migration لحد ما نوصل ال Migration اللي ال Migration Snapshot بتاعته سليمة وبعد كدا نضيف Migration جديد، والحل دا مشكلته انه ممكن يعمل Migrationضخم لو انت عملت Remove لأكتر من Migrationال Best Practicesفي بوست اليوم:-دايما حاول انك تعمل Branch rebasing او merge من ال mainعلى ال branchبتاعك باستمرار وخاصة قبل ما تعمل Migrations دا هيمنع اي conflicts مش بس في ال Migrations، بل لما ترجع تعمل mergeلل feature بتاعتك كمان-حاول ان كل Migrationيكون في commitمنفصلة

٢

السلام عليكم ورحمة الله وبركاتهدا البوست الخامس في سلسلة EF Core Migrations Best Practices واللي هنتكلم فيه عن "اللهو الخفي"،انا بسميه كدا لأنه مشكلة بتحصل ومحدش بياخد باله منها وبتفضل منتظرة حدث معين عشان تظهر والمشكلة تبان بعدهامبدئيا مفيش conflicts بتحصل في ال Migrations files نفسها لا في الملف الأساسي ولا في ملف ال designer، ودا لأن ال EF Core دايما بتحافظ على ان اسم ملف ال Migration يكون Unique ومش متكرر وبالتالي صعب يحصل Conflictsإلا إذا حصل تعديل يدوي من اكتر من مطور على نفس ال Migrationواحنا قولنا ان دا خطأال conflictsوارد تحصل في ال Model لو اكتر من ديفلوبر عدلوا على نفس ال Entity، كذلك ال ModelSnapshot ممكن يحصل فيها conflictsاللهو الخفي بيحصل في ال team environments لما اكتر من مطور يعملوا Migrations مختلفة على نفس ال Entity بس Attributes مختلفة او حتي على Entitiesمختلفة، وبعدين المطورين يعملوا Merge للشغل بتاعهم على ال Mainمن أهم اعراض اللهو الخفي اللي تعرفه بيها انك لما تعمل اضافة Migration جديد وانت بتراجع ال ()Up تلاقي تغييرات انت مش عاملها، مثلا لقيت اضافة ل column انت مضفتوش اصلاوال columnدا كان اضافه زميل لك في migration سابقالسبب الرئيسي للهو الخفي هو لما تستخدم Remove-Migration وال Snapshot بتاعت اخر Migration مش صحيحةناخد مثال، نفترض ان Dev1 شغال على Feature1وقام عامل Branchخاص بال Feature1دي من ال Mainوكمان Dev2شغال على Feature2 واخد Branch له من ال Mainنفترض ان اخر Migration في ال Main Branchكان Migration100 وبالتالي دا اصبح ال baseلأي migrationsجديدة هتتعمل في ال other branchesنفترض Dev1اضاف Migration101(101 هنا تشير ال timestamp عشان نعرف ترتيب ال Migrations ) وفيه اضاف columnجديد على Entityاسمها User ونفترض ان ال columnدا كان مثلا اسمه FullName واضاف ال Migration101، بعد كدا Dev2 عدل على نفس ال Entityواضاف columnاسمه IsActiveوبعد كدا اضاف Migration102نفترض انDev1 عمل Mergeللشغل بتاعه على ال Mainوأموره تمام، لما يجي Dev2ان شاء الله هو كمان يعمل Merge هيحصل conflictsفي ال ModelSnapshot لكن ال gitمشكورة هتحل ال conflictsمن نفسها لأن هنا التعديل مش في نفس ال property وبالتالي ال ModelSnapshot اصبح فيها ال FullName و ال IsActiveموجودين في ال User Entity والدنيا تمامدلوقتي ال migrations في ال mainبقي ترتيبها كدا:Migration100Migration101Migration102خلي بالك دلوقتي ان اخر Migration هو Migration102 اللي ترتبية بعد Migration101 المفترض ان ال Snapshotبتاعته تكون فيها التعديلات اللي عملها Migration101، لكن للأسف هي تفتقد اي معلومات عن ال FullName بسبب انها اتعملت في Branch مختلف معندوش فكره ان في مطور تاني اضاف Property اسمها FullNameدلوقتي اخر Migration ال Snapshot بتاعته بقت مختلفة عن ال ModelSnapshot، واحنا البوست السابق قولنا انه مهم جدا ان اخر Migration تكون ال Snapshotبتاعته مطابقة لل ModelSnapshotطيب دا ممكن يعمل مشكلة؟ في الأغلب الأمور ممكن تمشي وميحلصش مشاكل، لكن وراد يحصل مشكلة في السيناريو اللي هنقوله البوست القادم

٦

السلام عليكم ورحمة الله وبركاتهدا البوست الرابع في سلسلة EF Core Migrations Best Practices واللي هنتكلم فيه عن EFMigrationsHistory table__لما تقوم بإنشاء ال Database باستخدام ال EF Core هتلاقي في جدول خاص اسمه EFMigrationsHistory__ ، الجدول دا ال EF Core بتستخدمة عشان تخزن فيه ال اسماء ال Migrations اللي تم تنفيذها على ال Database، وعشان نعرف أهمية الجدول دا، خلونا ننفذ الأمر التاليPM> Update-Databaseالأمر دا ببساطة هيعمل Apply لأي Pending Migrations ولاحظ هنا كلمة Pendingبمعني انه لم يتم تنفيذه على ال Database، حيث ان ال EF Core بتعتبر ان اي Migration اسمه موجود في جدول ال EFMigrationsHistory__ انه تم تنفيذه واي Migration موجود في ال Codebase عندك ومش موجود في الEFMigrationsHistory __ هتعتبره Pendingباختصار، ال EF Core هتحصر قائمة ال Pending Migrations وهتنفذههم بالترتيب على ال Database، وبفرض ان ال Code base فيها ال Migrations التالية على الترتيب- Migration100 (باعتبار الرقم الخاص بال Migration يمثل ال timestamp)- Migration101- Migration102بفرض ان اخر Migration تم تنفيذه هو Migration100 وبالتالي اخر row في جدول EFMigrationsHistory_ هيكون فيه ال Migration100، وبالتالي قائمة ال Pending migrations هيكون فيها Migration101 و Migration102ولكل Migration في قائمة ال Pending Migrations هيتم التالي-بدء Transaction جديدة-تنفيذ ال Up Method-اضافة row جديد في جدول ال EFMigrationsHistory_ باسم ال Pending Migration اللي تم تنفيذه-إتمام ال Transactionوحيث انه تنفيذ اي Migration بيكون من خلال Transaction فدا بيضمن انه تنفيذ ال Up Method واضافة اسم ال Migration في جدول ال EFMigrationsHistory__ بيحصلوا او بيفشلوا مع بعض،لو في اي Migration فيه مشكلة وال EF Core مقدرش ينفذه، ال Execution pipeline مش هتكمل وهتقف عند ال Migration دا وهيفضل هو وما بعده من Migrations في ال Pending Migrations لحين اصلاح الخطأ وإعادة تنفيذ امر ال Update-Databaseطيب كدا فهما كيفية تنفيذ ال Migrations ودور الEFMigrationsHistory __ فيها، ماذا بخصوص ال Revert ل Migration او مجموعة Migrations تم بالفعل تنفيذهادا بيتم من خلال الأمر Update-Database كذلك، لكن من خلال اضافة Attribute اضافي<PM> Update-Database -Migration <nameهنا هيحصل عكس السيناريو السابق، حيث انه اي Migration تم تنفيذه بعد اسم ال Migration المذكور في الأمر السابق هيبقي تبع قائمة ال Reverted Migrations والتنفيذ بيكون من ال الأحدث للأقدم وبيحصل فيه التالي، لكل Migration في قائمة الReverted Migrations هيتم التالي-بدء Transaction جديدة-تنفيذ ال Down Method-حذف ال row الخاص بال Reverted Migration من جدول ال EFMigrationsHistory__-إتمام Commit ال Transactionفقط لاحظ ان عمل Revert لأي Migration لا يقوم بحذف ملفات ال Migrations من ال Migrations folder، كذلك لا يقوم بعمل اي تعديل في ال ModelSnapshotوبكدا نكون خلصنا ال components الأساسية في عملية ال Migration-ال ModelSnapshot-ال Migration file بشقية الملف الأساسي وملف ال Designer-جدول ال EFMigrationsHistory__-الأوامر الأساسيةالبوست القادم بمشيئة الله هيكون عن ال Conflictsنُشر من منصة Qabilah | قبيلة

١٣

٢ تعليق

السلام عليكم ورحمة الله وبركاتهدا البوست الثالث في سلسلة EF Core Migration Best Practices واللي هنكمل فيه كلام عن تاني component في عملية ال Migration وهو ال Migration file نفسههنتكلم ببساطة عن ال Remove-Migration command، الأمر دا بيتنفذ على اخر Migration تم اضافته وبالتالي هنا في حالتين أما تم تنفيذ ال Migration على ال Database أو لا.الحالة الأولي :لو لسه انت معملتش تنفيذ لل Migration، هنا فقط هيتم ارجاع ال ModelSnapshot لوضعه قبل اضافة ال Migration، كمان بيحذف ملف ال Migration من ال Migration folder، بيحذف الملف الأساسي وال Designerطيب السؤال هنا ازاي بيرجع ال ModelSnapshot لوضعه قبل اضافة ال Migration؟ هنا يبرز دور ال Designer.cs، يعني ال EF هتاخد ال Snapshot المحفوظة في ال Designer file بتاع ال Migration اللي قبل الأخير وتروح تحطة في ال ModelSnapshotالحالة الثانية: لو انت فعلا نفذت ال Migration على الداتابيز، هنا الأمر Remove-Migration مش هيشتغل وهيرجع لك رسالة خطأ، وعشان تجبره ينفذ لازم تزود عليه Force- ، هنا الأمر هيعمل مهمة ثالثة غير حذف الملف وتعديل ال ModelSnapshot، هنا هيتم تشغيل ال ()Down اللي موجودة في ال Migrationاللي هيتحذف عشان يظبط ال Database كمان وازالة اسم ال Migrationمن جدول الMigrationsHistory__ اللي موجود في ال Database، لكن دا في الإصدارات الحديثة من ال EFCoreاعتقد بداية من الإصدار الثامن، لكن الإصدارات السابقة كان Force- فقط لإرغام ال EF Coreعلى حذف ال Migration حتي لو تم تنفيذه على ال Databaseمع ترك ال Database كما هي

١١

١ تعليق واحد

السلام عليكم،دا أول مقال في قبيلة ولي عموما، لكن حابب اشكر كل الناس اللي بتقطتع جزء من وقتها عشان تكتب او تنتج شي مفيد للأخرين، فعلا مجرد كتابة مجموعة سطور امر مش سهلليه ال EF Core Migrations مهمة ومحتاجين نفهمها:أولأ: كل الناس اللي اشتغلت EF Core عملت مئات ال migrations لأنه ببساطة مش هتقدر تعكس التعديلات اللي بتعملها في ال Model بتاعك على ال Database إلا إذا عملت migration ونفذته، إذا هو مهم لأنه بيحافظ على إن ال Model وال Database يكونوا In Sync.ال Model ببساطة هو مجموعة ال Entities مع ال Fluent API Mapping اللي بتطبقها على ال entities دي وال migration مهمتة الأساسية انه يترجم ال Changes اللي انت بتعملها على ال Model دا لمجموعة من ال Scripts المتتالية اللي انت تقدر تنفذها في اي وقت وبالتالي تتنقل التعديلات من ال Model إلى Databaseكدا فهمنا ببساطة الغرض منه، تعالوا نتعرف المكونات الأساسية وازاي بيشتغل:· أول مكون هو ال Model Snapshot:ودا مهم جدا ومعظمنا مش بياخد باله منه، يمكن عشان ال EF Core بتضيفه بشكل تلقائي مع أول migration بتعمله واسمه بيكون اسم ال context مضافا إليه ModelSnapshot، يعني لو اسم ال context بتاعك "InvoicesContext" هيبقي اسم الملف InvoicesContextModelSnapshot.cs· طيب ايه هي وظيفته: من اسمه كدا ModelSnapshot فهو ملف بيحتفظ بلقطة من ال Model بعد اخر Migration عملته، طب ليه؟ ببساطة عشان لما تعمل migration جديد ال EF Core تقدر تعمل generation للملف بتاع ال migration.تخيل كدا انك كتبت الأمر دا PM> Add-Migration CreateInvoiceEntityببساطة هتلافي ملف جديد اتضاف لمجلد ال migrations اسمه CreateInvoiceEntity_TimeStamp، وال Time Stamp هنا مجرد بيانات معينة ال EF بتقراها من جهازك وتعمل لها append على اسم ال migration file بس عشان اسمه يبقي uniqueال EF Core ازاي بيقدر يستتنج الأكواد اللي اتضافت جوه ال migration file، ببساطة هو عنده base بيعتمد عليه وبيعتبره هو ال reference بتاعه اللي بيقيس عليه اي تعديلات انت عملتها في ال Model (Entities + Mapping)، وبكدا ال EF Core يقدر يطلع الفرق بين ال Model Snapshot اللي هو مخزنها ومابين ال Model بتاعك اللي انت عملت عليه تعديلات وبالتالي ال EF Core قدر يستتنج الفرق ويضيفه لل migration file بتاعك.طبعا الملف دا ال EF Core بتحدثه مع كل migration انت بتعمله، يعني لما بتعمل migration ال EF Core بتستخدم ال Model Snapshot عشان تعمل calculate لل migration file، وبعد كدا بتعدل ال Model Snapshot، وبالتالي لو بتستخدم اي source control زي git مثلا بص على ال pending changes هتلاقي من ضمنها ال Model Snapshot· طيب مهي الدنيا حلوة وال EF Core هو اللي بيعدله منه لنفسه بدون اي تدخل مننا، اه فعلا دا صحيح لكن في ال team environment ممكن يحصل Conflicts في الملف دا لو اي migration اتضاف من زميل تاني عدل فيه على نفس ال Entity او نفس ال Property اللي انت بتستخدمها في ال migration بتاعك.وبالتالي مهم اننا منعدلش الملف دا يدويا ودي أول Best Practice نتعلمها ولما يحصل ونلاقي merge conflicts ال git مش قادر يحلها مينفعش نعدل فيه بإيدنا ونحل ال conflicts ديطيب ازاي نحل ال conflicts دي، دا هنتعرف عليه في المقالات القادمة …نُشر من منصة Qabilah | قبيلة

٩

٢ تعليق

You can use my invitation link to join the emerging Arabic professional network, #qabilah !My invitation link: https://lnkd.in/drua_R9xPublished first at Qabilah | قبيلة

٢

You can use my invitation link to join the emerging Arabic professional network, #qabilah !My invitation link: https://lnkd.in/drua_R9xPublished first at Qabilah | قبيلة

١