سؤال

وجدت وهي المقالة MSDN أن يصف كيف EF مقابض التزامن عند حفظ التغييرات:

افتراضي [...] وجوه الخدمات يحفظ الكائن التغييرات إلى قاعدة البيانات دون التحقق من التوافق.بالنسبة الخصائص التي قد تواجه درجة عالية من التوافق ، ونحن نوصي بأن الهيئة الملكية تعريف مفاهيم طبقة مع سمة من ConcurrencyMode="ثابت"

لدي سؤالان:

  1. وجود خصائص في النموذج حيث ConcurrencyMode="fixed", هل هو آمن بالنسبة لي أن نفترض أنه إذا من أي وقت مضى OptimisticConcurrencyException يتم طرح عند حفظ التغييرات لأن الكيان لم يعد موجودا في مخزن البيانات ، أيأنه قد تم حذفه من قبل مستخدم آخر أو أنا في عداد المفقودين شيئا ؟

    أتصور EF تنفيذ UPDATE-بيان أن يبدو شيئا من هذا القبيل ، التي أرى أنها سوف تسبب OptimisticConcurrencyException أن يلقى إذا كان الشخص ID = 1 لا وجود له:

    UPDATE Person SET FirstName = 'John' AND LastName = 'Smith' WHERE ID = 1
    
  2. عند استخدام ConcurrencyMode="fixed", هل EF تحقق التزامن عند حذف الكيانات ؟ وبعبارة أخرى, سوف EF من أي وقت مضى تنفيذ DELETE-بيان أن يبدو مثل هذا (مع أكثر من مجرد المفتاح الأساسي في WHERE-شرط):

    DELETE FROM Person WHERE ID = 1 AND LastName = 'Doe'
    
هل كانت مفيدة؟

المحلول

سؤال جيد.

(1) نعم ، ولكن للأسف ليس هذا بسيط جدا.لأن EF (3.5) قد جمعية مستقلة نموذج جمعية تعامل بشكل مستقل أيضا ، حتى لو لم قال حتى يصبح جزءا من عمليات التزامن خلال التحديثات و يحذف.

أيعند تحديث الشخص سوف ترى في كثير من الأحيان التحديثات التي تبدو مثل هذا:

UPDATE Person SET Partner = NULL AND FirstName = 'John' AND LastName = 'Smith' 
WHERE ID = 1 AND Partner = 2

أيشريك هو FK العمود.

كل هذه التغييرات في 4.0 إذا كنت تستخدم FK الجمعيات ، كما نتوقع أن معظم الناس أيضا.

(2) على حذف أي ConcurrencyMode = 'ثابت' يتم التحقق من خصائص خلال حذف.الاستثناء هو عندما يكون لديك SPROC لحذف الذي لا يقبل أن التزامن القيم.

ويساعد هذا الأمل

اليكس

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top