JPA EntityManager:لماذا استخدام تستمر() على دمج()?

StackOverflow https://stackoverflow.com/questions/1069992

سؤال

EntityManager.merge() يمكن إدراج كائنات جديدة وتحديث القائم منها.

لماذا تريد استخدام persist() (التي يمكن أن تؤدي إلا إلى خلق كائنات جديدة)?

هل كانت مفيدة؟

المحلول

وفي كلتا الحالتين سوف تضيف كيان لPersistenceContext، والفرق هو في ما تفعله مع الكيان بعد ذلك.

وتستمر يأخذ مثيل كيان، ويضيف أن السياق ويجعل من هذا المثال تمكن (سيتم تعقب أي التحديثات المستقبلية للكيان).

ودمج يخلق مثيل جديد من الكيان الخاص، ونسخا الدولة من الجهة الموردة، ويجعل نسخة جديدة تمكن. لن تمكن سبيل المثال قمت بتمرير في (فإن أي تغييرات تقوم بها لن تكون جزءا من الصفقة - إلا إذا كنت الدعوة دمج مرة أخرى).

وربما سوف المثال رمز المساعدة. 

MyEntity e = new MyEntity();

// scenario 1
// tran starts
em.persist(e); 
e.setSomeField(someValue); 
// tran ends, and the row for someField is updated in the database

// scenario 2
// tran starts
e = new MyEntity();
em.merge(e);
e.setSomeField(anotherValue); 
// tran ends but the row for someField is not updated in the database
// (you made the changes *after* merging)

// scenario 3
// tran starts
e = new MyEntity();
MyEntity e2 = em.merge(e);
e2.setSomeField(anotherValue); 
// tran ends and the row for someField is updated
// (the changes were made to e2, not e)

والسيناريو 1 و 3 وتعادل تقريبا، ولكن هناك بعض الحالات حيث كنت ترغب في استخدام السيناريو 2.

نصائح أخرى

تستمر ودمج هي لغرضين مختلفين (أنهم ليسوا البدائل على الإطلاق).

(تحرير لتوسيع الخلافات المعلومات)

تستمر:

  • إدراج سجل جديد إلى قاعدة البيانات
  • إرفاق كائن إلى الكيان مدير.

دمج:

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

تستمر() الكفاءة:

  • يمكن أن يكون أكثر كفاءة من أجل إدراج سجل جديد في قاعدة بيانات من دمج().
  • لا التكرارات الكائن الأصلي.

تستمر() دلالات:

  • يجعل متأكد من أنك إدخال و لا تحديث عن طريق الخطأ.

على سبيل المثال:

{
    AnyEntity newEntity;
    AnyEntity nonAttachedEntity;
    AnyEntity attachedEntity;

    // Create a new entity and persist it        
    newEntity = new AnyEntity();
    em.persist(newEntity);

    // Save 1 to the database at next flush
    newEntity.setValue(1);

    // Create a new entity with the same Id than the persisted one.
    AnyEntity nonAttachedEntity = new AnyEntity();
    nonAttachedEntity.setId(newEntity.getId());

    // Save 2 to the database at next flush instead of 1!!!
    nonAttachedEntity.setValue(2);
    attachedEntity = em.merge(nonAttachedEntity);

    // This condition returns true
    // merge has found the already attached object (newEntity) and returns it.
    if(attachedEntity==newEntity) {
            System.out.print("They are the same object!");
    }

    // Set 3 to value
    attachedEntity.setValue(3);
    // Really, now both are the same object. Prints 3
    System.out.println(newEntity.getValue());

    // Modify the un attached object has no effect to the entity manager
    // nor to the other objects
    nonAttachedEntity.setValue(42);
}

هذا الطريق موجود فقط 1 المرفقة كائن أي سجل في الكيان مدير.

دمج() لكيان مع معرف هو شيء من هذا القبيل:

AnyEntity myMerge(AnyEntity entityToSave) {
    AnyEntity attached = em.find(AnyEntity.class, entityToSave.getId());
    if(attached==null) {
            attached = new AnyEntity();
            em.persist(attached);
    }
    BeanUtils.copyProperties(attached, entityToSave);

    return attached;
}

على الرغم من أن إذا كان متصلا إلى الخلية دمج() يمكن أن تكون فعالة قدر تستمر() استخدام دعوة إلى إدراج مع تكرار تحديث مفتاح الخيار ، JPA هو البرمجة على مستوى عال جدا وأنت لا يمكن أن نفترض أن هذا هو الحال في كل مكان.

إذا كنت تستخدم تعيين مولد ، باستخدام دمج بدلا من قائمة يمكن أن يسبب زائدة SQL, وبالتالي تؤثر على الأداء.

أيضا ، داعيا دمج المدارة الكيانات هو أيضا خطأ حيث تمكنت الجهات تلقائيا تدار من قبل السبات و الدولة متزامنة مع قاعدة بيانات سجل من قبل القذرة آلية التحقق عند التنظيف استمرار السياق.

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

مرة واحدة في كيان بنشاط تدار من قبل السبات ، جميع التغييرات ستكون تلقائيا نشر إلى قاعدة البيانات.

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

أولا يجب أن نحدد كل كيان الدول:

  • جديدة (عابر)

    تم إنشاؤه حديثا والكائن التي لم تكن في أي وقت مضى المرتبطة السبات Session (أ.ك.a Persistence Context) و لم يتم تعيينها إلى أي قاعدة بيانات صف الجدول يعتبر في الجديد (عابر) دولة.

    لتصبح استمرت علينا إما بشكل صريح استدعاء EntityManager#persist طريقة أو متعدية استمرار آلية.

  • الثابتة (المدارة)

    استمرار الكيان ارتبط مع جدول قاعدة بيانات الصف وانها تدار من قبل التيار تشغيل استمرار السياق.أي تغيير يطرأ على هذا الكيان سوف يتم الكشف عن نشر قاعدة البيانات (خلال الدورة دافق الوقت).مع السبات ، لم يعد لدينا لتنفيذ إدراج/تحديث/حذف البيانات.السبات توظف المعاملات الكتابة خلف العامل أسلوب مزامنة التغييرات في آخر المسؤولة اللحظة الحالية Session دافق الوقت.

  • منفصل

    بمجرد تشغيل الحالي سياق استمرار إغلاق جميع تمكنت في وقت سابق من الكيانات أصبحت منفصلة.التغييرات المتتالية لن يتم تعقب أي التزامن التلقائي لقاعدة البيانات سوف يحدث.

    لربط منفصل كيان نشط السبات الدورة يمكنك اختيار واحد من الخيارات التالية:

    • واعادة ربط

      السبات (ولكن ليس JPA 2.1) يدعم واعادة ربط من خلال الدورة#طريقة التحديث.وهو السبات الدورة فقط المنتسبين كيان واحد كائن قاعدة بيانات معين الصف.وذلك لأن استمرار سياق الأعمال في ذاكرة التخزين المؤقت (المستوى الأول ذاكرة التخزين المؤقت) و قيمة واحدة فقط (كيان) يرتبط إلى مفتاح معين (الكيان نوع بيانات معرف).كيان يمكن تثبيتها إلا إذا كان لا يوجد غيرها JVM كائن (مطابقة نفس قاعدة البيانات صف) المرتبطة بالفعل الحالية السبات الدورة.

    • دمج

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

  • إزالة

    على الرغم من أن JPA المطالب التي تمكنت الجهات فقط يسمح إزالة السبات يمكن أيضا حذف فصل الكيانات (ولكن فقط من خلال جلسة#حذف استدعاء الأسلوب).إزالة الكيان المقرر فقط للحذف و قاعدة البيانات الفعلية DELETE سيتم تنفيذها خلال الدورة دافق الوقت.

فهم JPA الدولة التحولات أفضل, يمكنك تصور الرسم البياني التالي:

enter image description here

أو إذا كنت تستخدم السبات محددة API:

enter image description here

ولقد لاحظت أنه عندما كنت em.merge، حصلت على بيان SELECT لكل INSERT، حتى عندما لم يكن هناك مجال أن النقابة وتوليد بالنسبة لي - كان حقل المفتاح الأساسي لUUID أن أضع نفسي. أنا تحولت إلى em.persist(myEntityObject) وحصلت على مجرد تصريحات INSERT ذلك الحين.

JPA مواصفات يقول ما يلي عن persist().

إذا X هو كائن منفصل ، EntityExistsException قد تكون القيت عندما تستمر عملية الاحتجاج ، أو EntityExistsException أو آخر PersistenceException قد تكون القيت في مسح أو تخصيص وقت.

وذلك باستخدام persist() من شأنها أن تكون مناسبة عند الكائن لا يجب أن تكون منفصلة الكائن.قد تفضل أن يكون رمز رمي PersistenceException لذلك فشل سريع.

على الرغم من أن مواصفات غير واضح, persist() فقد ترغب في تعيين @GeneratedValue @Id لكائن. merge() ومع ذلك يجب أن يكون كائن مع @Id ولدت بالفعل.

وهناك بعض الاختلافات بين أكثر merge وpersist (سوف تعداد مرة أخرى تلك التي نشرت بالفعل هنا):

وD1. merge لا يجعل تمكن الكيان مرت، وإنما يعود مثال آخر التي يتم إدارتها. سوف persist على الجانب الآخر جعل إدارة الكيان مرت: 

//MERGE: passedEntity remains unmanaged, but newEntity will be managed
Entity newEntity = em.merge(passedEntity);

//PERSIST: passedEntity will be managed after this
em.persist(passedEntity);

وD2. إذا قمت بإزالة كيان ومن ثم تقرر أن تستمر الكيان الظهر، يمكنك فعل ذلك فقط مع الاستمرار ()، لأن merge سوف بطرح IllegalArgumentException.

وD3. إذا كنت قررت أن تأخذ الرعاية يدويا من معرفات الخاص بك (على سبيل المثال باستخدام UUIDs)، ثم merge وعملية تؤدي الاستفسارات SELECT اللاحقة لكي تبدو للكيانات موجودة مع أن ID، في حين persist قد لا تحتاج تلك الاستفسارات.

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

بعض مزيد من التفاصيل حول دمج والتي سوف تساعدك على استخدام دمج أكثر من قائمة:

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

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

في وجود علاقات الدمج() عملية محاولة تحديث تمكن الكيان إلى نقطة إدارة الإصدارات من الكيانات المشار إليها من قبل كيان منفصل.إذا كان الكيان لديه العلاقة كائن لا استمرار الهوية, نتيجة دمج العملية غير معرف.بعض مقدمي قد تسمح تمكنت من نسخ إلى نقطة عدم استمرار الكائن ، في حين أن البعض الآخر قد رمي استثناء على الفور.دمج() العملية يمكن أن يكون اختياريا تتالي في هذه الحالات لمنع استثناء من الحدوث.نحن سوف تغطي المتتالية من دمج() العملية لاحقا في هذا القسم.إذا كيان دمج النقاط إلى إزالة الكيان ، IllegalArgumentException استثناء سيتم طرح.

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

جميع المعلومات المذكورة أعلاه مأخوذة من "برو JPA 2 اتقان جافا Tm استمرار API" مايك كيث ميريك Schnicariol.الفصل 6.القسم مفرزة ودمج.هذا الكتاب هو في الواقع الكتاب الثاني خصص JPA من قبل المؤلفين.هذا الكتاب الجديد لديه العديد من المعلومات الجديدة السابق ثم واحدة.أنا حقا ريكوميد إلى قراءة هذا الكتاب هم الذين سوف تشارك بجدية مع JPA.أنا آسف على anonimously نشر أول الجواب.

وكنت الحصول على استثناءات lazyLoading على كيان بلدي لأنني كنت تحاول الوصول إلى مجموعة تحميل كسول التي كانت في الدورة.

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

لتخفيف هذا، وأنا تحديثها الكيان نفسه في وحدة التحكم الخاصة بي ونقلوها الى بلدي التخطيط الاستراتيجي المشترك، على الرغم من أنني أتصور عندما أنا أعيد حفظها أثناء الدورة التي سوف تكون في متناول الرغم SessionScope أيضا وليس رمي LazyLoadingException، تعديل المثال 2:

لقد عملت ما يلي بالنسبة لي: 

// scenario 2 MY WAY
// tran starts
e = new MyEntity();
e = em.merge(e); // re-assign to the same entity "e"

//access e from jsp and it will work dandy!!

وتمر الإجابات هناك بعض التفاصيل في عداد المفقودين فيما يتعلق `كاسكيد" وجيل الهوية. <وأ href = "https://stackoverflow.com/questions/17816196/jpa-how-can-i-get-the-generated-id-object-when-using-merge-from-parent-but-child/17830782 # 17830782 "> انظر السؤال

وبالإضافة إلى ذلك، تجدر الإشارة إلى أنه يمكن أن يكون الشروح Cascade منفصلة لدمج واستمرار: Cascade.MERGE وCascade.PERSIST التي سيتم التعامل معها وفقا للطريقة المستخدمة

ووالمواصفات هي صديقك؛)

وجدت هذا التفسير من السبات مستندات المنير, لأنها تحتوي على حالة الاستخدام:

استخدام دلالات دمج() ويبدو أن مربكة للمستخدمين الجدد.أولا: طالما أنك لا تحاول استخدام كائن الدولة تحميلها في كيان واحد مدير في كيان آخر جديد مدير, يجب عليك لا تحتاج إلى استخدام دمج() في جميع.بعض كله التطبيقات لن تستخدم هذا الأسلوب.

عادة دمج() يستخدم في السيناريو التالي:

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

وهنا بالضبط الدلالي من دمج():

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

من: http://docs.jboss.org/hibernate/entitymanager/3.6/reference/en/html/objectstate.html

JPA هو بلا منازع تبسيط كبير في مجال المشاريع تطبيقات مبنية على منصة جافا.كمطور الذي كان التعامل مع تعقيدات القديمة الكيان الفول في J2EE أرى إدراج JPA بين Java EE المواصفات قفزة كبيرة إلى الأمام.ومع ذلك ، في حين الخوض أعمق JPA تفاصيل أجد الأشياء التي ليس من السهل.في هذه المادة أنا أتعامل مع مقارنة على EntityManager دمج وتستمر الأساليب التي متداخلة السلوك قد يسبب الارتباك ليس فقط مبتدئ.وعلاوة على ذلك أنا اقتراح التعميم الذي يرى كل الأساليب حالات خاصة أعم طريقة الجمع.

استمرار الكيانات

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

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

enter image description here

مواصفات يذهب أكثر في التفاصيل ، ومع ذلك ، تذكر لهم ليست حاسمة مثل هذه التفاصيل تغطية أكثر أو أقل الحالات الغريبة فقط.

دمج الكيانات

في مقارنة مستمرة ، وصف دمج السلوك ليست بهذه البساطة.لا يوجد السيناريو الرئيسي كما في حالة مستمرة ، و مبرمج يجب أن تذكر جميع السيناريوهات من أجل كتابة الكود الصحيح.يبدو لي أن JPA المصممين أراد أن يكون بعض الطريقة التي الشاغل سيكون التعامل مع كيانات منفصلة (كما عكس تستمر الأسلوب الذي يتعامل مع الكيانات المنشأة حديثا في المقام الأول.) دمج الأسلوب المهمة الرئيسية لنقل الدولة من غير مدارة الكيان (كما مر الحجة) إلى تمكن نظيره في استمرار السياق.هذه المهمة بيد أن يقسم كذلك في العديد من السيناريوهات التي تزداد سوءا وضوح الأسلوب الشامل السلوك.

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

enter image description here

لذا متى يجب استخدام قائمة عندما يدمج ؟

تستمر

  • تريد طريقة دائما يخلق كيان جديد و لم التحديثات كيان.وإلا فإن طريقة يطرح استثناء نتيجة المفتاح الأساسي تفرد انتهاك.
  • دفعة عمليات التعامل مع الكيانات في جليل الطريقة (انظر بوابة نمط).
  • الأداء الأمثل

دمج

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

والسيناريو X:

والجدول: Spitter (واحد)، الجدول: Spittles (كثير) (Spittles هو المالك للعلاقة مع FK: spitter_id)

وهذه نتائج هذا السيناريو في توفير: إن Spitter وكلا Spittles كما لو يملكها نفس Spitter

. 
        Spitter spitter=new Spitter();  
    Spittle spittle3=new Spittle();     
    spitter.setUsername("George");
    spitter.setPassword("test1234");
    spittle3.setSpittle("I love java 2");       
    spittle3.setSpitter(spitter);               
    dao.addSpittle(spittle3); // <--persist     
    Spittle spittle=new Spittle();
    spittle.setSpittle("I love java");
    spittle.setSpitter(spitter);        
    dao.saveSpittle(spittle); //<-- merge!!

والسيناريو Y:

وهذا سيوفر على Spitter، سيوفر على 2 Spittles لكنهم لن ترجع نفس Spitter! 

        Spitter spitter=new Spitter();  
    Spittle spittle3=new Spittle();     
    spitter.setUsername("George");
    spitter.setPassword("test1234");
    spittle3.setSpittle("I love java 2");       
    spittle3.setSpitter(spitter);               
    dao.save(spittle3); // <--merge!!       
    Spittle spittle=new Spittle();
    spittle.setSpittle("I love java");
    spittle.setSpitter(spitter);        
    dao.saveSpittle(spittle); //<-- merge!!

وملاحظة أخرى:

وmerge() سوف يهتمون إلا لمعرف الذي تم إنشاؤه تلقائيا (اختبار على IDENTITY وSEQUENCE) عندما سجل مع هذا معرف مسبقا في الجدول الخاص بك. في هذه الحالة merge() سوف محاولة تحديث السجل. ولكن، إذا معرف غائب أو غير مطابقة أي السجلات الموجودة، وmerge() تجاهله تماما ونسأل ديسيبل لتخصيص واحدة جديدة. هذا في بعض الأحيان مصدرا للكثير من الخلل. لا تستخدم merge() إلى فرض هوية للرقما قياسيا جديدا.

وpersist() من ناحية أخرى لن تسمح حتى قمت بتمرير معرف إليها. وسوف تفشل على الفور. في حالتي، انها:

<اقتباس فقرة>   

والناجمة عن: org.hibernate.PersistentObjectException: فصل كيان   مرت على الاستمرار

وجافادوك السبات-النقابة لديه تلميح:

<اقتباس فقرة>   

<القوي> الرميات : لjavax.persistence.EntityExistsException - إذا كان الكيان   موجود مسبقا. (إذا كان الكيان موجودا مسبقا،   EntityExistsException قد يكون طرح عندما تستمر العملية   الاحتجاج، أو EntityExistsException أو PersistenceException آخر   قد يكون طرح في وقت دافق أو ارتكاب).

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

دعونا نفترض يمكنك استخدام مفتاح الطبيعية/معرف.

  • البيانات يجب أن تكون مستمرة ، ولكن مرة واحدة في حين سجل موجود و التحديث المطلوب.في هذه الحالة يمكنك محاولة مستمرة وإذا كان يلقي EntityExistsException, كنت ابحث عنه و الجمع بين البيانات:

    محاولة { entityManager.تستمر(كيان) }

    الصيد(EntityExistsException استثناء) { /* استرداد ودمج */ }

  • استمرت البيانات يحتاج إلى تحديث ، ولكن مرة واحدة في حين لا يوجد تسجيل البيانات حتى الآن.في هذه الحالة يمكنك البحث عنه و لا تستمر إذا كان الكيان مفقود:

    كيان = entityManager.العثور على(مفتاح);

    إذا (كيان == null) { entityManager.تستمر(كيان) ؛ }

    آخر { /* دمج */ }

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

وقد يدمج يمكن التعامل معها بطريقتين أيضا:

  1. إذا كانت التغييرات عادة ما تكون صغيرة ، وتطبيقها على تمكن الكيان.
  2. إن التغيرات شائعة ، نسخ معرف من استمرار الكيان ، وكذلك دون تغيير البيانات.ثم استدعاء EntityManager::دمج() لتحل محل القديمة المحتوى.

وينبغي أن تستخدم مع كيانات جديدة تماما لا تزال قائمة (كيان)، لإضافتها إلى DB (إذا كيان موجود بالفعل في DB سيكون هناك EntityExistsException رمي).

ودمج (الكيان) وينبغي أن تستخدم، لوضع كيان إلى سياق استمرار إذا تم فصل كيان وتم تغيير.

وربما ما زالت قائمة وتوليد بيان INSERT SQL ودمج بيان تحديث SQL (ولكن لست متأكدا).

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