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.
This commit is contained in:
@@ -0,0 +1,17 @@
|
||||
Scenario: load an order, then read its customer's id through the
|
||||
AggregateReference — never call customerRepository.findById for it.
|
||||
|
||||
1. SELECT "JDBC_ORDER"."ID" AS "ID", "JDBC_ORDER"."VERSION" AS "VERSION", "JDBC_ORDER"."CUSTOMER_ID" AS "CUSTOMER_ID" FROM "JDBC_ORDER" WHERE "JDBC_ORDER"."ID" = ?
|
||||
2. SELECT "JDBC_ORDER_ITEM"."ID" AS "ID", "JDBC_ORDER_ITEM"."SKU" AS "SKU", "JDBC_ORDER_ITEM"."QUANTITY" AS "QUANTITY", "JDBC_ORDER_ITEM"."ORDER_KEY" AS "ORDER_KEY" FROM "JDBC_ORDER_ITEM" WHERE "JDBC_ORDER_ITEM"."ORDER_ID" = ? ORDER BY "ORDER_KEY"
|
||||
|
||||
total statements: 2
|
||||
|
||||
statements touching jdbc_customer: 0
|
||||
customer id obtained without a lookup: 3
|
||||
|
||||
AggregateReference<Customer, Long> is a typed foreign key: getId() is free
|
||||
because the id is literally the column value already in hand from loading the
|
||||
order. Nothing about Customer is fetched unless you explicitly ask a
|
||||
CustomerRepository for it. This is the mechanism that keeps a multi-aggregate
|
||||
object graph from becoming N+1 by default — there is no "default" traversal at
|
||||
all across an aggregate boundary.
|
||||
Reference in New Issue
Block a user