data access
Spring Data JPA
Get CRUD repositories for free by declaring an interface — no implementation needed.
Spring Data JPA removes the most repetitive layer in a typical application: the data-access code. Instead of writing a class full of boilerplate find, save, and delete methods backed by an EntityManager, you declare an interface, and Spring generates the implementation at runtime. The promise is that you describe what you want to query, not how to fetch it.
You write the menu (interface); Spring builds the kitchen automatically.
Key Concepts
1
You extend JpaRepository<Entity, IdType>, and immediately inherit a full set of CRUD and pagination operations — save, findById, findAll, delete, plus sorting and paging. For anything beyond that, derived query methods let you express a query in the method name: findByEmailAndActiveTrue is parsed into the corresponding query automatically. When the name would get unwieldy, you drop to an explicit @Query with JPQL or native SQL. At startup Spring scans these interfaces, creates proxy implementations, and registers them as beans you can inject. Because it sits on top of JPA/Hibernate, you still get the object-relational mapping, the persistence context, and dirty checking — modifying a managed entity inside a transaction flushes the change without an explicit save.
JpaRepository<Entity, IdType>savefindByIdfindAlldelete
2
The expertise interviews look for is awareness of the leaky abstraction underneath. The N+1 query problem is the headline issue: lazily-loaded associations trigger a separate query per parent row, which a JOIN FETCH or an entity graph fixes. You should understand lazy versus eager fetching and why LazyInitializationException happens outside a transaction, the difference between getReference (a proxy) and findById (a real load), and that derived queries are convenient but can hide expensive SQL — so for complex reporting or bulk updates, explicit queries or even JdbcTemplate are often the better tool.
JOIN FETCHLazyInitializationExceptiongetReferencefindById
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "How do derived query methods work?" *Probing:* the mechanism. *Stalls:* "Magic." *Moves up:*
the method name is parsed into a query at startup, so a typo fails at context load rather than at
runtime.
1. "How do derived query methods work?"
5
2. "What causes the N+1 problem here?" *Probing:* the classic. *Stalls:* "Too many rows." *Moves
up:* lazy associations accessed in a loop, so a list of 100 triggers 101 queries — fixed with a
fetch join or an entity graph.
2. "What causes the N+1 problem here?"
6
3. "What is the difference between getReferenceById and findById?" *Probing:* the detail.
*Stalls:* "Nothing." *Moves up:* getReferenceById returns a lazy proxy without hitting the database
until accessed; findById loads immediately.
3. "What is the difference between getReferenceById and findById?"
7
4. "When would you drop to a projection or native query?" *Probing:* judgement. *Stalls:*
"Never." *Moves up:* when you need a few columns or a query JPQL cannot express — loading whole
entities for a list view is wasteful.
4. "When would you drop to a projection or native query?"