ควรใช้งานเท่ากับและแฮชโค้ดอย่างไรเมื่อใช้ JPA และ Hibernate

คลาสโมเดลควรมีการใช้งานเท่ากับและแฮชโค้ดในไฮเบอร์เนตอย่างไร อะไรคือข้อผิดพลาดที่พบบ่อย? การใช้งานเริ่มต้นดีเพียงพอสำหรับกรณีส่วนใหญ่หรือไม่ การใช้คีย์ธุรกิจมีความหมายหรือไม่?

สำหรับฉันแล้วดูเหมือนว่ามันค่อนข้างยากที่จะทำให้มันทำงานได้ถูกต้องในทุกสถานการณ์เมื่อคำนึงถึงการดึงข้อมูลการสร้างรหัสพร็อกซีและอื่น ๆ

Hibernate มีคำอธิบายที่ดีและยาวเกี่ยวกับเวลา / วิธีการลบล้างequals()/ hashCode()ในเอกสาร

ความสำคัญของมันคือคุณต้องกังวลเกี่ยวกับเรื่องนี้ว่าเอนทิตีของคุณจะเป็นส่วนหนึ่งของSetหรือถ้าคุณกำลังจะถอด / แนบอินสแตนซ์ หลังไม่ธรรมดานั้น อดีตมักจะจัดการได้ดีที่สุดผ่าน:

1. ฐานequals()/hashCode()บนคีย์ธุรกิจ - เช่นชุดค่าผสมเฉพาะของแอตทริบิวต์ที่จะไม่เปลี่ยนแปลงในช่วงอายุการใช้งานของออบเจ็กต์ (หรืออย่างน้อยเซสชัน)
2. หากเป็นไปไม่ได้ข้างต้นให้ใช้พื้นฐานequals()/ hashCode()บนคีย์หลักหากมีการตั้งค่าและข้อมูลประจำตัวของวัตถุ / System.identityHashCode()มิฉะนั้น สำคัญส่วนหนึ่งที่นี่เป็นที่ที่คุณต้องโหลดชุดของคุณหลังจากที่องค์กรใหม่ได้รับการเพิ่มและยืนยัน; มิฉะนั้นคุณอาจท้ายด้วยพฤติกรรมแปลก (ที่สุดส่งผลให้เกิดข้อผิดพลาดและ / หรือความเสียหายของข้อมูล) hashCode()เพราะนิติบุคคลของคุณอาจจะจัดสรรให้กับถังที่ไม่ตรงกับปัจจุบัน

ฉันไม่คิดว่าคำตอบที่ยอมรับนั้นถูกต้อง

ในการตอบคำถามเดิม:

การใช้งานเริ่มต้นดีเพียงพอสำหรับกรณีส่วนใหญ่หรือไม่

คำตอบคือใช่ในกรณีส่วนใหญ่คือ

คุณเพียงแค่ต้องลบล้างequals()และhashcode()หากเอนทิตีจะถูกใช้ใน a Set(ซึ่งเป็นเรื่องธรรมดามาก) และเอนทิตีนั้นจะถูกแยกออกจากนั้นและต่อมาจะเชื่อมต่ออีกครั้งกับเซสชันไฮเบอร์เนต (ซึ่งเป็นการใช้ไฮเบอร์เนตที่ผิดปกติ)

คำตอบที่ได้รับการยอมรับระบุว่าเมธอดจำเป็นต้องถูกลบล้างหากเงื่อนไขใดเงื่อนไขหนึ่งเป็นจริง

ที่ดีที่สุดequals/ hashCodeการดำเนินงานคือเมื่อคุณใช้คีย์ธุรกิจที่ไม่ซ้ำกัน

คีย์ธุรกิจควรสอดคล้องกันในการเปลี่ยนสถานะเอนทิตีทั้งหมด(ชั่วคราว, แนบ, แยก, ลบ) นั่นเป็นเหตุผลที่คุณไม่สามารถพึ่งพา id เพื่อความเท่าเทียมกันได้

อีกทางเลือกหนึ่งคือการเปลี่ยนไปใช้ตัวระบุ UUIDซึ่งกำหนดโดยตรรกะของแอปพลิเคชัน ด้วยวิธีนี้คุณสามารถใช้ UUID สำหรับequals/ hashCodeเนื่องจาก id ถูกกำหนดก่อนที่เอนทิตีจะถูกล้าง

คุณยังสามารถใช้ตัวระบุเอนทิตีสำหรับequalsและhashCodeแต่ต้องให้คุณคืนhashCodeค่าเดียวกันเสมอเพื่อให้แน่ใจว่าค่าแฮชโค้ดเอนทิตีสอดคล้องกันในการเปลี่ยนสถานะเอนทิตีทั้งหมด ดูโพสต์นี้สำหรับข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อนี้

เมื่อเอนทิตีถูกโหลดผ่านการโหลดแบบขี้เกียจมันไม่ใช่อินสแตนซ์ของประเภทพื้นฐาน แต่เป็นประเภทย่อยที่สร้างขึ้นแบบไดนามิกที่สร้างขึ้นโดย javassist ดังนั้นการตรวจสอบประเภทคลาสเดียวกันจะล้มเหลวดังนั้นอย่าใช้:

if (getClass() != that.getClass()) return false;

ใช้แทน:

if (!(otherObject instanceof Unit)) return false;

ซึ่งยังเป็นวิธีที่ดีตามที่อธิบายไว้ในการดำเนินการเท่ากับใน Java การปฏิบัติ

ด้วยเหตุผลเดียวกันการเข้าถึงฟิลด์โดยตรงอาจไม่ทำงานและส่งคืนค่าว่างแทนค่าพื้นฐานดังนั้นอย่าใช้การเปรียบเทียบกับคุณสมบัติ แต่ใช้ getters เนื่องจากอาจทำให้เกิดการโหลดค่าพื้นฐาน

ใช่มันยาก ในโปรเจ็กต์ของฉันเท่ากับและ hashCode ทั้งสองอาศัย id ของอ็อบเจ็กต์ ปัญหาของวิธีแก้ปัญหานี้คือทั้งสองอย่างไม่ทำงานหากวัตถุยังไม่ถูกคงอยู่เนื่องจาก id ถูกสร้างขึ้นโดยฐานข้อมูล ในกรณีของฉันมันสามารถยอมรับได้เนื่องจากในเกือบทุกกรณีวัตถุยังคงอยู่ในทันที นอกจากนั้นยังใช้งานได้ดีและใช้งานง่าย

ในเอกสารของ Hibernate 5.2 ระบุว่าคุณอาจไม่ต้องการใช้ hashCode และเท่ากับเลย - ขึ้นอยู่กับสถานการณ์ของคุณ

https://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#mapping-model-pojo-equalshashcode

โดยทั่วไปวัตถุสองชิ้นที่โหลดจากเซสชันเดียวกันจะเท่ากันหากมีค่าเท่ากันในฐานข้อมูล (โดยไม่ต้องใช้ hashCode และเท่ากับ)

จะซับซ้อนหากคุณใช้สองเซสชันขึ้นไป ในกรณีนี้ความเท่าเทียมกันของวัตถุสองชิ้นขึ้นอยู่กับการใช้วิธีการเท่ากับของคุณ

นอกจากนี้คุณจะประสบปัญหาหากวิธีการเท่ากับของคุณกำลังเปรียบเทียบ ID ที่สร้างขึ้นในขณะที่ยังคงมีวัตถุเป็นครั้งแรก พวกเขาอาจยังไม่อยู่ที่นั่นเมื่อเรียกเท่ากับ

มีบทความดีๆอยู่ที่นี่: https://docs.jboss.org/hibernate/stable/core.old/reference/en/html/persistent-classes-equalshashcode.html

อ้างถึงบรรทัดสำคัญจากบทความ:

เราขอแนะนำให้ใช้ equals () และ hashCode () โดยใช้ Business key equivalent ความเท่าเทียมกันของคีย์ธุรกิจหมายความว่าวิธีการ equals () จะเปรียบเทียบเฉพาะคุณสมบัติที่เป็นคีย์ธุรกิจซึ่งเป็นคีย์ที่ระบุอินสแตนซ์ของเราในโลกแห่งความเป็นจริง (คีย์ตัวเลือกตามธรรมชาติ):

พูดง่ายๆคือ

public class Cat {

...
public boolean equals(Object other) {
    //Basic test / class cast
    return this.catId==other.catId;
}

public int hashCode() {
    int result;

    return 3*this.catId; //any primenumber 
}

}

หากคุณเกิดขึ้นเพื่อลบล้างequalsตรวจสอบให้แน่ใจว่าคุณปฏิบัติตามสัญญา: -

• สมมาตร
• สะท้อนกลับ
• เปลี่ยน
• สม่ำเสมอ
• ไม่เป็นโมฆะ

และลบล้างhashCodeเนื่องจากสัญญาขึ้นอยู่กับequalsการใช้งาน

Joshua Bloch (ผู้ออกแบบกรอบงาน Collection) ขอเรียกร้องให้ปฏิบัติตามกฎเหล่านี้อย่างจริงจัง

• ข้อ 9: แทนที่ hashCode เสมอเมื่อคุณลบล้างเท่ากับ

มีผลร้ายแรงโดยไม่ได้ตั้งใจเมื่อคุณไม่ทำตามสัญญาเหล่านี้ ตัวอย่างเช่นList#contains(Object o)อาจส่งคืนbooleanค่าที่ไม่ถูกต้องเนื่องจากไม่ปฏิบัติตามสัญญาทั่วไป