Чим JPA orphanRemoval = true відрізняється від пункту ON DELETE CASCADE DML

Я трохи заплутався в orphanRemovalатрибуті JPA 2.0 .

Я думаю, що я можу побачити, що це потрібно, коли я використовую інструменти генерації БД свого постачальника JPA для створення базової бази даних DDL, щоб мати ON DELETE CASCADEконкретне відношення.

Однак, якщо БД існує і вона вже має ON DELETE CASCADEвідношення, чи цього недостатньо для каскадування видалення належним чином? Що робить orphanRemovalдодатково?

Ура

orphanRemovalне має нічого спільного ON DELETE CASCADE.

orphanRemoval- цілком специфічна для ORM річ . Він позначає "дочірнє" об'єкт, яке потрібно видалити, коли на нього більше не посилається "батьківський" об'єкт, наприклад, коли ви вилучаєте дочірнє об'єкт із відповідної колекції батьківського об'єкта.

ON DELETE CASCADE- специфічна для бази даних річ , вона видаляє "дочірню" рядок у базі даних, коли "батьківський" рядок видалено.

Приклад, сформований тут :

Коли Employeeоб'єкт сутності видалено, операція видалення каскадується до Addressоб'єкта, що посилається . У зв'язку з цим orphanRemoval=trueі cascade=CascadeType.REMOVEє ідентичними, і якщо orphanRemoval=trueвони вказані, CascadeType.REMOVEє зайвими.

Різниця між двома параметрами полягає у відповіді на відключення відносини. Наприклад, наприклад, при встановленні адресного поля nullна інший Addressоб’єкт або на нього .

• Якщо orphanRemoval=trueвказано, відключений Addressекземпляр автоматично видаляється. Це корисно для очищення залежних об'єктів (наприклад Address), які не повинні існувати без посилання власника на об'єкт (наприклад Employee).

• Якщо cascade=CascadeType.REMOVEвказано лише , ніяких автоматичних дій не буде вжито, оскільки відключення зв'язку не є операцією видалення.

Щоб уникнути звисання посилань у результаті видалення сиріт, цю функцію слід увімкнути лише для полів, що містять приватні об'єкти, що не належать до спільного доступу.

Сподіваюся, це робить це більш зрозумілим.

Щойно ви вилучите добірку з колекції, ви також будете видаляти це дочірнє утворення з БД. Орфографічне вилучення також означає, що ви не можете змінити батьків; якщо у відділі є співробітники, після того, як ви видалите цього співробітника, щоб перевести його в інше відділення, ви ненавмисно видалить цього співробітника з БД при флеш-фіксації (що відбувається раніше). Мораль полягає в тому, щоб встановити «Сирітське усунення» на істину до тих пір, поки ви впевнені, що діти цього батька не будуть переходити до іншого батька протягом свого існування. Якщо ввімкнути orphanRemoval, також автоматично додається REMOVE до списку каскадів.

Еквівалентне відображення JPA для DDL ON DELETE CASCADEє cascade=CascadeType.REMOVE. Видалення сиріт означає, що залежні особи видаляються, коли знищуються відносини до їх "батьківського" об'єкта. Наприклад, якщо дитину відсторонили від @OneToManyвідносин, не видаляючи її чітко у менеджера юридичних осіб.

Різниця полягає в:
- orphanRemoval = true: "Дочірнє" об'єкт видаляється, коли на нього більше не посилається (його батьківський засіб може бути видалено).
- CascadeType.REMOVE: "Дочірнє" об'єкт видаляється лише тоді, коли видалено його "Батько".

Оскільки це дуже поширене питання, я написав цю статтю , на якій ґрунтується ця відповідь.

Переходи сутності держави

JPA переводить переходи стану сутності в оператори SQL, такі як INSERT, UPDATE або DELETE.

Коли ви persistє суб'єктом господарювання, ви плануєте оператор INSERT, який буде виконуватися при EntityManagerзмиванні, автоматично або вручну.

коли ви removeє суб'єктом господарювання, ви плануєте оператор DELETE, який буде виконаний, коли контекст персистентності змитий.

Каскадні переходи стану сутності

Для зручності JPA дозволяє розповсюджувати переходи стану суб'єктів господарювання від материнських об'єктів до дочірнього.

Отже, якщо у вас є материнське Postпідприємство, яке має @OneToManyасоціацію з PostCommentдочірнім об'єктом:

commentsКолекція в Postсутності, відображається наступним чином :

@OneToMany(
    mappedBy = "post", 
    cascade = CascadeType.ALL,
    orphanRemoval = true
)
private List<Comment> comments = new ArrayList<>();

CascadeType.ALL

cascadeАтрибут повідомляє постачальник JPA передати об'єкт стан переходу від батьківського Postоб'єкта для всіх PostCommentосіб , які утримуються в commentsколекції.

Отже, якщо ви видалите Postсутність:

Post post = entityManager.find(Post.class, 1L);
assertEquals(2, post.getComments().size());

entityManager.remove(post);

Постачальник JPA збирається спочатку видалити PostCommentоб'єкт, а коли всі дочірні сутності будуть видалені, він також видалить Postсутність:

DELETE FROM post_comment WHERE id = 1
DELETE FROM post_comment WHERE id = 2

DELETE FROM post WHERE id = 1

Видалення сиріт

Коли ви встановите orphanRemovalатрибут на true, постачальник JPA планує запланувати removeоперацію, коли дочірнє об'єднання буде видалено з колекції.

Отже, у нашому випадку

Post post = entityManager.find(Post.class, 1L);
assertEquals(2, post.getComments().size());

PostComment postComment = post.getComments().get(0);
assertEquals(1L, postComment.getId());

post.getComments().remove(postComment);

Постачальник JPA збирається видалити пов'язаний post_commentзапис, оскільки сукупність PostCommentбільше не посилається на commentsколекцію:

DELETE FROM post_comment WHERE id = 1

НА ВИДАЛЕННІ КАСКАДИ

Значення ON DELETE CASCADEвизначається на рівні FK:

ALTER TABLE post_comment 
ADD CONSTRAINT fk_post_comment_post_id 
FOREIGN KEY (post_id) REFERENCES post 
ON DELETE CASCADE;

Після цього ви видалите postрядок:

DELETE FROM post WHERE id = 1

Усі асоційовані post_commentоб'єкти автоматично видаляються двигуном бази даних. Однак це може бути дуже небезпечною операцією, якщо ви видалите кореневу сутність помилково.

Висновок

Перевага JPA cascadeта orphanRemovalваріантів полягає в тому, що ви також можете скористатися оптимістичним блокуванням, щоб запобігти втраченим оновленням .

Якщо ви використовуєте каскадний механізм JPA, вам не потрібно використовувати рівень DDL ON DELETE CASCADE, що може бути дуже небезпечною операцією, якщо ви видалите кореневу сутність, яка має багато дочірніх сутностей на кількох рівнях.

Більш детально про цю тему перегляньте цю статтю .

Відповідь @GaryK абсолютно чудова, я витратив годину на пошуки пояснення orphanRemoval = trueпроти, CascadeType.REMOVEі це допомогло мені зрозуміти.

Підбиття підсумків: orphanRemoval = trueпрацює ідентично, CascadeType.REMOVE ТІЛЬКО ЯКЩО ми видаляємо об'єкт ( entityManager.delete(object)), і ми хочемо, щоб дочірні об’єкти також були видалені.

При зовсім іншому оцінюванні, коли ми отримуємо деякі дані, як-от, List<Child> childs = object.getChilds()а потім видаляємо дочірню ( entityManager.remove(childs.get(0)), використовуючи, це orphanRemoval=trueпризведе до того, що це об'єкт childs.get(0)буде видалено з бази даних.

Вилучення сиріт має той же ефект, що і НА ВИДАЛЕННЯ КАСКАДУ за наступним сценарієм: - Скажімо, у нас є прості відносини між студентом та керівництвом, що мають багато простих до одного, коли багато студентів можуть бути відображені в одному керівництві, а в базі даних у нас є зовнішнє ключове відношення між таблицею Student і Guide таким чином, що таблиця студента має id_guide як FK.

    @Entity
    @Table(name = "student", catalog = "helloworld")
    public class Student implements java.io.Serializable {
     @Id
     @GeneratedValue(strategy = IDENTITY)
     @Column(name = "id")
     private Integer id;

    @ManyToOne(cascade={CascadeType.PERSIST,CascadeType.REMOVE})
    @JoinColumn(name = "id_guide")
    private Guide guide;

// Батьківська сутність

    @Entity
    @Table(name = "guide", catalog = "helloworld")
    public class Guide implements java.io.Serializable {

/**
 * 
 */
private static final long serialVersionUID = 9017118664546491038L;

@Id
@GeneratedValue(strategy = IDENTITY)
@Column(name = "id", unique = true, nullable = false)
private Integer id;

@Column(name = "name", length = 45)
private String name;

@Column(name = "salary", length = 45)
private String salary;


 @OneToMany(mappedBy = "guide", orphanRemoval=true) 
 private Set<Student> students = new  HashSet<Student>(0);

У цьому випадку відносини є такими, що студентська сутність є власником відносин, і тому нам потрібно зберегти студентське об'єднання, щоб зберегти весь графік об'єкта, наприклад

    Guide guide = new Guide("John", "$1500");
    Student s1 = new Student(guide, "Roy","ECE");
    Student s2 = new Student(guide, "Nick", "ECE");
    em.persist(s1);
    em.persist(s2);

Тут ми відображаємо один і той же посібник з двома різними студентськими об’єктами, і оскільки використовується CASCADE.PERSIST, графік об'єктів буде збережено, як показано нижче, в таблиці бази даних (MySql в моєму випадку)

СТУДЕНТСЬКА таблиця: -

Ідентифікатор Ім'я Депт Id_Guide

1 Рой ЄЕК 1

2 Нік ECE 1

Таблиця довідника: -

ID NAME Зарплата

1 Джон 1500 доларів США

і тепер, якщо я хочу видалити одного з учнів, використовуючи

      Student student1 = em.find(Student.class,1);
      em.remove(student1);

і коли видаляється запис студента, відповідний запис керівництва також повинен бути видалений, саме тут атрибут CASCADE.REMOVE в об'єкті Student входить у зображення і що він робить, він видаляє студента з ідентифікатором 1, а також відповідний керівний об'єкт (ідентифікатор 1). Але в цьому прикладі є ще один об'єкт для студентів, який відображається у тому самому записі керівництва, і, якщо ми не використаємо атрибут orphanRemoval = true в Entity Guide, код видалення вище не буде працювати.