Files
sdjpa4-demo/jdbc-vs-jpa/docs/output/05-orphan-removal-delete.txt
asmhatre 448c383879 Add jdbc-vs-jpa module: Spring Data JDBC vs JPA on a shared Order aggregate
Same Customer/Order/OrderItem domain modelled with Hibernate/Spring Data JPA and
Spring Data JDBC side by side, both running through a shared StatementLoggingDataSource
so SQL-statement counts are directly comparable. 11 tests, 11 captured transcripts,
6 doc chapters. Companion repo for the ankurm.com article on when to drop the ORM.
2026-09-17 19:09:35 +00:00

12 lines
694 B
Plaintext

Scenario: remove one item from order.items (a plain List.remove, via the
addItem/removeItem helpers that keep both sides in sync) and save() the order.
1. select o1_0.id,c1_0.id,c1_0.name,i1_0.order_id,i1_0.id,i1_0.quantity,i1_0.sku,o1_0.version from jpa_order o1_0 left join jpa_customer c1_0 on c1_0.id=o1_0.customer_id left join jpa_order_item i1_0 on o1_0.id=i1_0.order_id where o1_0.id=?
2. delete from jpa_order_item where id=?
total statements: 2
orphanRemoval = true on the @OneToMany turns "no longer in the collection" into
a DELETE for that row. Without orphanRemoval, the row survives with a dangling
(nulled or stale) order_id, which is the more common real-world bug report.