orphanRemoval и разрыв связи: DELETE

1. remove() ≠ DELETE в БД

Представьте, что вы ведёте заказ (PurchaseOrder) и его позиции (OrderItem). В Java всё выглядит дружелюбно: есть order.getItems() и можно сделать remove(). Кажется логичным, что позиция исчезнет “везде”. Но Hibernate мыслит не эмоциями, а внешними ключами, flush()-циклом и правилами связи. В результате в памяти позиция исчезла, а в БД строка осталась — и вы получаете “висячие” данные или ошибки ограничений.

Давайте нарисуем типичный сценарий из нашего Commerce Persistence Lab.

У нас есть связь:

- PurchaseOrder содержит коллекцию items
- OrderItem содержит ссылку order (и именно здесь, как мы уже знаем, обычно живёт внешний ключ order_id)

Наивный код выглядит так:

import jakarta.persistence.EntityManager;

PurchaseOrder order = em.find(PurchaseOrder.class, 1L);
OrderItem item = em.find(OrderItem.class, 10L);

// Удаляем элемент из коллекции родителя (в памяти он “пропал”)
order.getItems().remove(item);

// Принудительно отправляем накопленные изменения в БД, чтобы увидеть реальный SQL
em.flush();

С точки зрения разработчика-новичка это почти магия: “я же удалил из списка”. А Hibernate отвечает: “ты удалил из коллекции, которая не управляет внешним ключом (inverse side), и вообще непонятно, что ты хочешь: отвязать позицию от заказа или удалить позицию как сущность”.

И тут всплывает первый жизненный вопрос, который в ORM нужно задавать чаще, чем “почему оно не работает”:

Позиция заказа (OrderItem) может жить без заказа (PurchaseOrder)?

Если “нет”, то хранить OrderItem отдельно в таблице без заказа — бессмысленно. Это и есть классическая ситуация для orphanRemoval.

2. Что такое orphanRemoval

Когда вы впервые видите слово orphanRemoval, мозг рисует драму: “сироты”, “удаление”, “необратимо”. И это… довольно близко к правде. orphanRemoval = true — это настройка маппинга, которая говорит Hibernate: если child-entity больше не принадлежит parent-entity (то есть связь разорвана), то child нужно удалить (DELETE). Не “отвязать”, не “оставить на потом”, а именно удалить строку из БД.

В JPA это выглядит так: вы включаете orphanRemoval на @OneToMany (или @OneToOne) со стороны родителя:

import jakarta.persistence.CascadeType;
import jakarta.persistence.OneToMany;

@OneToMany(
        mappedBy = "order", // inverse side: внешний ключ живёт НЕ здесь
        cascade = {CascadeType.PERSIST, CascadeType.REMOVE}, // создаём вместе с parent, удаляем вместе с ним
        orphanRemoval = true // “нет родителя — нет ребёнка”: разорвали связь => DELETE
)
private java.util.List<OrderItem> items;

Здесь важны две мысли.

Первая: orphanRemoval — это не “удали по кнопке”. Это правило жизненного цикла. Как только объект становится “сиротой” в терминах связи, Hibernate на flush() переводит его в состояние removed и делает DELETE.

Вторая: orphanRemoval не заменяет понимание owning side. Он не отменяет того факта, что внешний ключ живёт на стороне @ManyToOne. Он просто добавляет новое правило: “разрыв связи = удаление сущности”.

Если захотите аналогию, то вот максимально бытовая: OrderItem в нашем домене — это не “самостоятельный предмет мебели”, а “ножка от стула”. Отдельно ножка может существовать физически, но в вашей модели данных она бессмысленна. Поэтому правило “ножка без стула — в мусорку” как раз и есть orphanRemoval.

3. orphanRemoval и CascadeType.REMOVE

Когда начинающий разработчик видит CascadeType.REMOVE и orphanRemoval, он часто думает: “оба про удаление, значит одно и то же”. Это ровно тот момент, когда Hibernate собирает чемодан и уезжает в отпуск, оставляя вам ConstraintViolationException. Потому что удаление действительно одно (DELETE), а вот когда оно должно произойти — два разных мира.

Сравним по-человечески:

Пример для CascadeType.REMOVE (удаляем заказ целиком):

import jakarta.persistence.EntityManager;

PurchaseOrder order = em.find(PurchaseOrder.class, 1L);

// Триггер здесь: удаляем parent-сущность
em.remove(order);

// SQL уйдёт на flush/commit: ожидаем DELETE по заказу и детям (если каскад настроен)
em.flush();

Пример для orphanRemoval (заказ остаётся, удаляем позицию как “часть заказа”):

import jakarta.persistence.EntityManager;

PurchaseOrder order = em.find(PurchaseOrder.class, 1L);
OrderItem item = em.find(OrderItem.class, 10L);

// Триггер здесь: разрыв связи (ребёнок перестаёт принадлежать родителю)
order.removeItem(item);

// На flush/commit Hibernate удалит child как orphan (DELETE из order_item)
em.flush();

И это принципиально важно в бизнес-логике. Заказ может оставаться, но позицию вы удалили из заказа — и она должна исчезнуть из БД, потому что отдельной жизни у неё нет.

4. Как работает orphanRemoval

Чтобы orphanRemoval перестал выглядеть как “волшебная галочка”, важно увидеть механику. Hibernate не бегает по объектам сразу после remove() из коллекции и не удаляет строку в тот же момент. Он работает в режиме unit of work: изменения копятся в persistence context, а SQL уходит на flush() (явный или автоматический). Поэтому orphanRemoval — это тоже история про persistence context и flush-cycle, просто с акцентом на удаление.

Происходит примерно такая цепочка.

Во время транзакции Hibernate держит в persistence context managed-объекты и их снапшоты. Коллекции типа order.items — это не просто “ArrayList”, а persistent collection, которая умеет помнить, что из неё удалили элемент. Когда вы вызываете helper-метод и убираете OrderItem из items, Hibernate отмечает изменение коллекции. Если orphanRemoval = true, то “удалённый из коллекции элемент” становится кандидатом на удаление как сущность.

Но тут есть тонкость, которая связывает тему с лекциями про owning side и helper-методы. Если вы удалили элемент только из коллекции, но оставили у него item.setOrder(this), вы создали рассинхрон: inverse side говорит “его больше нет в заказе”, owning side говорит “он всё ещё принадлежит заказу”. В таких ситуациях Hibernate может вести себя неожиданно, а отладка превращается в шаманство. Поэтому в нормальном приложении вы делаете remove-операцию согласованно, обновляя обе стороны.

Вот мини-схема (в очень упрощённом виде), что мы хотим получить:

flowchart TD
  %% Разрыв связи в объектной модели + flush => DELETE в БД (при orphanRemoval = true)
  A["items.remove(item)"] --> B["item.setOrder(null)"]
  B --> C["flush()"]
  C --> D[Hibernate видит orphan]
  D --> E[DELETE из order_item]

И обратите внимание на ключевое слово: flush. Если вы не дошли до flush (или commit), вы видите изменения только в памяти. Для диагностики orphan removal почти всегда полезно сделать entityManager.flush() специально, чтобы “вынести SQL на свет” и перестать гадать.

5. Практика: удаляем OrderItem через orphanRemoval

Сейчас мы соберём всё в максимально приземлённый сценарий: заказ живёт, позиция удаляется, и мы хотим увидеть честный DELETE в SQL-логе. Я намеренно делаю примеры маленькими и “в лоб”, потому что на этом этапе курса нам важнее предсказуемость, чем красота архитектуры. Красота придёт, когда у вас появится устойчивое понимание поведения ORM (и немного терпения).

И на этой связке уже полезно собрать один рабочий snapshot целиком. OrderItem в нашем варианте — часть заказа: создаётся вместе с заказом, удаляется вместе с заказом, а при разрыве связи должен исчезать из БД. Поэтому на relation достаточно PERSIST и REMOVE; обычные изменения полей child всё равно поймает dirty checking.

Маппинг: где включаем orphanRemoval

Нам нужна типичная двунаправленная связь PurchaseOrder (1) -> (N) OrderItem. На стороне заказа мы включаем orphan removal:

import jakarta.persistence.CascadeType;
import jakarta.persistence.OneToMany;

@OneToMany(
        mappedBy = "order", // inverse side, FK будет на стороне OrderItem
        cascade = {CascadeType.PERSIST, CascadeType.REMOVE}, // создаём позиции вместе с заказом, удаляем вместе с заказом
        orphanRemoval = true // удалили из коллекции => удалить строку в БД (на flush/commit)
)
private java.util.List<OrderItem> items = new java.util.ArrayList<>();

А на стороне позиции заказа у нас owning side (@ManyToOne), через которую в таблице order_item живёт order_id:

import jakarta.persistence.JoinColumn;
import jakarta.persistence.ManyToOne;

@ManyToOne(optional = false) // в домене позиция не должна существовать без заказа
@JoinColumn(name = "order_id", nullable = false) // FK not null: “отвязать” нельзя, только удалить
private PurchaseOrder order;

Здесь nullable = false очень жизненный: позиция заказа без заказа не имеет смысла и не должна существовать в БД как отдельная строка “в никуда”.

Helper-метод: разрываем связь корректно

Теперь ключевая часть: helper-метод removeItem(). Он не должен быть “удалить из списка” и всё. Он должен обновить обе стороны, чтобы owning side тоже стала “пустой”.

public void removeItem(OrderItem item) {
    // Убираем из коллекции родителя (inverse side)
    items.remove(item);

    // Обновляем owning side, чтобы FK-ссылка тоже считалась разорванной
    item.setOrder(null);
}

Да, это всего две строки. И да, именно эти две строки спасают вас от целого класса ORM-странностей. Hibernate, конечно, умный, но он не читает ваши мысли. Если в графе объектов осталось item.order = this, он вправе считать, что вы “пока ещё не определились”.

В этой модели OrderItem не “переезжает” молча между заказами. Remove здесь значит именно разорвать связь и дать Hibernate удалить orphan, а не quietly переподвесить позицию на другой PurchaseOrder.

Сервисный сценарий: удаляем позицию и делаем flush()

Сделаем маленький сервисный метод, который работает внутри транзакции, чтобы PurchaseOrder и OrderItem были managed:

import jakarta.persistence.EntityManager;
import org.springframework.transaction.annotation.Transactional;

@Transactional
public void removeItemFromOrder(long orderId, long itemId, EntityManager em) {
    // Оба объекта должны быть managed в persistence context
    PurchaseOrder order = em.find(PurchaseOrder.class, orderId);
    OrderItem item = em.find(OrderItem.class, itemId);

    // Разрываем связь “как часть агрегата”: при orphanRemoval это означает удаление child
    order.removeItem(item);

    // “Фонарик” для лаборатории: прямо сейчас увидеть SQL, а не ждать commit
    em.flush();
}

Я специально оставил flush() внутри метода. В боевом коде вы часто полагаетесь на flush при commit, но в учебной лаборатории flush — это “фонарик”: подсветить, что реально будет отправлено в БД.

Ожидаемый SQL (упрощённо, по смыслу):

-- orphanRemoval = true: разрыв связи приводит к удалению строки
delete from order_item where id = ?;

Если у вас включён sql-trace профиль, вы увидите и bind-параметры. И вот это тот момент, когда фраза “удалили из коллекции” становится проверяемой: удаление из коллекции + orphan removal = delete ребёнка на flush.

6. Без orphanRemoval: отвязать ≠ удалить

Иногда разработчик говорит: “я не хочу orphanRemoval, я хочу контролировать удаление руками”. Это может быть осознанным решением. Но важно понимать, какую реальность вы себе выбираете. Без orphan removal разрыв связи чаще всего означает не DELETE, а попытку сделать FK NULL (если это вообще разрешено).

Представим, что у нас было так:

import jakarta.persistence.OneToMany;

@OneToMany(mappedBy = "order") // orphanRemoval выключен: разрыв связи не означает DELETE
private java.util.List<OrderItem> items = new java.util.ArrayList<>();

И вы вызываете:

// Разрываем связь на уровне объектов, но без orphanRemoval это ещё не “удаление”
order.removeItem(item);

// На flush Hibernate будет пытаться “согласовать” FK-столбец в БД
em.flush();

Дальше возможны два мира.

Если order_id nullable, Hibernate может сделать примерно это:

-- Разрыв связи без orphanRemoval часто превращается в “обнуление FK”
update order_item set order_id = null where id = ?;

И тогда у вас остаётся строка order_item, которая больше ни к чему не привязана. Это и есть “сирота” на уровне базы данных, только уже в плохом смысле слова. В домене заказа такая строка обычно бессмысленна.

Если же order_id NOT NULL (а он часто должен быть NOT NULL), то попытка “отвязать” позицию превращается в ошибку ограничений. Вы хотите всего лишь убрать позицию, а получаете исключение, которое выглядит так, будто вы сломали мир.

В этом месте разработчики часто делают “рефлекторную заплатку”: добавляют где-нибудь repository.delete(item) или em.remove(item), но забывают обновить коллекцию у заказа. И тогда в памяти коллекция всё ещё содержит удалённый объект. Hibernate это не любит, а ваш будущий коллега — тем более.

То есть без orphanRemoval вам нужно удерживать дисциплину вручную: если позиция больше не нужна, вы должны явно удалить сущность и согласованно убрать её из коллекции. orphanRemoval просто кодирует эту дисциплину в маппинг, чтобы вы не повторяли одно и то же в каждом сервисе.

7. Где уместен orphanRemoval

Давайте чуть расширим взгляд: orphanRemoval — не “фича для заказов”. Это общий инструмент для связей, где child не должен иметь самостоятельной жизни. В нашем проекте ещё один кандидат — Customer и его адреса CustomerAddress. Но, как и всегда в ORM, “можно” не значит “нужно”. Выбор упирается в доменное правило.

Если адрес — это сущность, которая существует только как часть клиента (например, “адрес доставки клиента №123”), то orphanRemoval логичен: адрес без клиента не имеет смысла, и при удалении адреса из профиля мы ожидаем DELETE соответствующей строки.

Маппинг может выглядеть так:

import jakarta.persistence.CascadeType;
import jakarta.persistence.OneToMany;

@OneToMany(
        mappedBy = "customer", // inverse side
        cascade = {CascadeType.PERSIST, CascadeType.REMOVE}, // адреса создаём вместе с клиентом, удаляем вместе с ним
        orphanRemoval = true // убрали адрес из коллекции клиента => удалить строку адреса
)
private java.util.List<CustomerAddress> addresses = new java.util.ArrayList<>();

Но если по вашей бизнес-логике адрес может “пережить” переезд к другому клиенту, или вы храните адреса как справочник, или вам нужен журнал изменений адресов (не удалять, а “закрывать”), то orphanRemoval становится опасным. Потому что “убрал из коллекции” будет означать “удалил строку”, а не “переназначил” или “скрыл”.

Поэтому правило выбора очень простое (и максимально практичное): если вы готовы сказать “child не может и не должен существовать без parent” — orphanRemoval подходит. Если сомневаетесь — скорее всего, не подходит. ORM в этом месте не обязан угадывать вашу предметную область.

8. Типичные ошибки при использовании orphanRemoval

Ошибка №1: удаляют ребёнка только из коллекции и забывают обновить owning side.
Снаружи кажется, что “я же убрал item из order.getItems()”, но если вы не занулили item.setOrder(null) (или не обновили owning side другим способом), вы создаёте рассинхрон в объектной модели. В лучшем случае Hibernate сделает не тот SQL, который вы ожидали. В худшем — вы получите состояние, которое трудно объяснить и ещё труднее воспроизвести.

Ошибка №2: воспринимают orphanRemoval как замену CascadeType.REMOVE.
orphanRemoval не означает “удаляй детей, когда удаляю родителя”. Он означает “удаляй ребёнка, когда он больше не принадлежит родителю”. Это разные триггеры. Если вы удаляете PurchaseOrder, а каскад REMOVE не настроен (и нет DB-level cascade), позиции могут остаться, и вы получите проблемы с FK. Удаление родителя и разрыв связи — разные бизнес-события.

Ошибка №3: ждут DELETE “сразу”, а не на flush().
Пока вы в транзакции, без flush(), изменения живут в persistence context. Часто люди смотрят в отладчик, видят “в коллекции элемента нет” и думают, что строка уже удалена. Но реальный критерий истины — SQL на flush/commit. Поэтому для диагностики orphan removal почти всегда полезно делать явный em.flush() в лабораторном сценарии.

Ошибка №4: пытаются “переместить” ребёнка к другому родителю, когда включён orphanRemoval.
С orphanRemoval вы фактически говорите: “если ребёнка сняли с родителя — удалить”. Если в вашем коде есть промежуточный шаг “снять, потом поставить к другому” в рамках одной транзакции, Hibernate может успеть запланировать удаление. Это приводит к очень странным эффектам: вы как будто переносите объект, а он в итоге удаляется. Если вам нужно перемещение — это сигнал, что orphanRemoval, возможно, не отражает вашу модель.

Ошибка №5: включают orphanRemoval там, где ребёнок не является “частью” родителя, а является общей сущностью.
Классический пример “плохой идеи” — ставить orphan removal (или cascade remove) на @ManyToOne к общей сущности, вроде Product. Позиция заказа удаляется — товар внезапно исчезает из каталога. Это не баг Hibernate, это ваше правило жизненного цикла, которое вы случайно закодировали в маппинг. ORM послушно выполнил приказ, а потом вы долго объясняете бизнесу, почему “товары пропадают сами”.