asmhatre
448c383879
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.
18 lines
1.0 KiB
Plaintext
18 lines
1.0 KiB
Plaintext
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.
|