https://devops-monk.com/tutorials/spring-data-jpa/Recent content in Spring Data JPA Tutorial — Complete Guide on Devops MonkHugoen-usMon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/mapped-superclass/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/mapped-superclass/Introduction Almost every entity in a real application shares a few common fields: id, createdAt, updatedAt, and perhaps version. Writing these in every entity class is repetitive and error-prone. @MappedSuperclass lets you define them once in a base class that all entities extend — without creating a parent table or any inheritance mapping in the database. What Is @MappedSuperclass? @MappedSuperclass marks a class whose field mappings are inherited by subclass entities.https://devops-monk.com/tutorials/spring-data-jpa/transactional-propagation-isolation/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/transactional-propagation-isolation/What @Transactional Does @Transactional tells Spring to wrap the annotated method in a database transaction. Spring opens the transaction before the method starts and commits (or rolls back) when it ends. The annotation works via an AOP proxy — understanding this proxy model is essential for avoiding the most common @Transactional bugs. The AOP Proxy Model Spring creates a proxy around your bean. When code outside the bean calls a @Transactional method, the call goes through the proxy, which manages the transaction:https://devops-monk.com/tutorials/spring-data-jpa/auditing/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/auditing/Why Auditing Matters Production systems must answer: “Who changed this? When? What did it look like before?” Without auditing infrastructure, you add created_at, updated_at, created_by, updated_by columns manually to every entity — dozens of lines of boilerplate repeated everywhere. Spring Data JPA auditing fills these fields automatically. Hibernate Envers goes further: it captures every revision of every entity in separate audit tables. Spring Data JPA Auditing Enable Auditing @Configuration @EnableJpaAuditing(auditorAwareRef = "auditorProvider") public class JpaAuditingConfig { @Bean public AuditorAware<String> auditorProvider() { return () -> Optional.https://devops-monk.com/tutorials/spring-data-jpa/basic-entity-mapping/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/basic-entity-mapping/Introduction Entity mapping is the process of telling Hibernate how your Java class corresponds to a database table, and how each field maps to a column. JPA provides a rich set of annotations for this — from the minimal @Entity and @Id to the detailed @Column with constraints. This article covers every annotation and attribute you need to map entities precisely and confidently. @Entity @Entity marks a class as a JPA entity — a Java object that maps to a database table.https://devops-monk.com/tutorials/spring-data-jpa/cascade-types-orphan-removal/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/cascade-types-orphan-removal/Introduction Cascade types control which persistence operations (save, merge, delete, refresh) propagate from a parent entity to its associated children. orphanRemoval controls what happens when a child is removed from the parent’s collection. Getting cascade wrong is one of the most common causes of unexpected deletes and data integrity issues in JPA applications. The Six Cascade Types cascade = CascadeType.PERSIST // propagate persist (save new entity) cascade = CascadeType.MERGE // propagate merge (re-attach detached entity) cascade = CascadeType.https://devops-monk.com/tutorials/spring-data-jpa/custom-queries-jpql-native-sql/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/custom-queries-jpql-native-sql/Why @Query Exists Derived query methods (Article 17) are great for simple conditions, but they break down fast. A method like findByOrderStatusAndCustomerCityAndPriceBetweenOrderByCreatedAtDesc is unreadable and still cannot express a JOIN or aggregation. @Query lets you write the exact JPQL or SQL you need, attached directly to a repository method — keeping your repository clean while giving you full query control. JPQL vs Native SQL JPQL Native SQL Language Entity/field names Table/column names Database portable Yes No JOIN FETCH Yes No Window functions No Yes Full-text search No Yes Complex analytics Limited Full power Start with JPQL.https://devops-monk.com/tutorials/spring-data-jpa/custom-type-conversions/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/custom-type-conversions/Introduction JPA handles most Java types automatically — String, Integer, LocalDate, BigDecimal. But what about a Java enum? A List<String> stored as JSON? A custom Money type? JPA’s AttributeConverter and @Enumerated let you control exactly how any Java type maps to a database column. Mapping Enums with @Enumerated Java enums are common in domain models. JPA maps them with @Enumerated: public enum OrderStatus { PENDING, CONFIRMED, SHIPPED, DELIVERED, CANCELLED } public enum ProductStatus { ACTIVE, INACTIVE, DISCONTINUED } @Column(length = 20, nullable = false) @Enumerated(EnumType.https://devops-monk.com/tutorials/spring-data-jpa/dirty-checking-flush-modes/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/dirty-checking-flush-modes/The Persistence Context Revisited Article 3 introduced the persistence context — the in-memory cache of managed entities. This article goes deeper: how does the persistence context detect changes? When does it flush them to the database? And how can you tune this behaviour? Dirty Checking When you modify a managed entity, you don’t call save() or update(). You simply change the field: @Transactional public void giveDiscount(Long productId, BigDecimal discount) { Product product = productRepository.https://devops-monk.com/tutorials/spring-data-jpa/embedded-types-value-objects/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/embedded-types-value-objects/Introduction Not every concept in your domain deserves its own table. An Address — street, city, state, postal code — is a value object: it has no identity of its own, it belongs to an entity. JPA’s @Embeddable lets you model this as a separate Java class while storing it in the owning entity’s table. What Is an Embeddable? An @Embeddable class is a Java class whose fields are mapped to columns in the owning entity’s table — not a separate table.https://devops-monk.com/tutorials/spring-data-jpa/entity-graphs-batch-loading/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/entity-graphs-batch-loading/The Problem @EntityGraph Solves JOIN FETCH in @Query solves N+1 but creates inflexibility: the fetch plan is baked into the query. Two different use cases — an order detail page (needs items + customer) and an order list page (needs only customer) — require two different queries with different JOIN FETCHes. @EntityGraph separates the fetch plan from the query. You define what to load at the call site, and Spring Data JPA generates the appropriate JOIN.https://devops-monk.com/tutorials/spring-data-jpa/entity-lifecycle-states/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/entity-lifecycle-states/Introduction Every JPA entity is always in one of four states. The state determines whether Hibernate is tracking the entity, whether changes are detected automatically, and what operations are valid. Understanding these states explains a large class of JPA bugs — especially the dreaded LazyInitializationException and detached entity errors. The Four States new Customer() │ │ persist / save() ▼ TRANSIENT ──────────────────────► MANAGED (not tracked) (tracked by persistence context) │ │ evict / clear / close ▼ DETACHED (no longer tracked) │ │ merge() ▼ MANAGED (re-attached) MANAGED ─── remove / delete() ──► REMOVED (delete scheduled, still in context) 1.https://devops-monk.com/tutorials/spring-data-jpa/fetch-types-eager-vs-lazy/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/fetch-types-eager-vs-lazy/Introduction Every relationship in JPA has a fetch type: either EAGER (load immediately with the parent) or LAZY (load only when accessed). The defaults are counterintuitive, and getting fetch types wrong is one of the top causes of performance problems and LazyInitializationException in JPA applications. Default Fetch Types Annotation Default fetch type Performance risk @ManyToOne EAGER Loads related entity on every query — can be expensive @OneToOne EAGER Same — loads profile/address on every customer load @OneToMany LAZY Correct default — collections are only loaded when needed @ManyToMany LAZY Correct default The defaults for @ManyToOne and @OneToOne are EAGER — a poor choice that the JPA spec made for historical reasons.https://devops-monk.com/tutorials/spring-data-jpa/inheritance-strategies/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/inheritance-strategies/Introduction Object-oriented code uses inheritance to share behaviour. Relational databases have no concept of inheritance. JPA bridges this gap with three strategies for mapping a class hierarchy to tables. Understanding when each is appropriate prevents schema headaches and performance problems. The Domain Example An e-commerce system has different types of discount: Discount (abstract) ├── PercentageDiscount (e.g., 10% off) └── FixedAmountDiscount (e.g., $5 off) All discounts share: id, name, validFrom, validUntil. PercentageDiscount adds: percentage (e.https://devops-monk.com/tutorials/spring-data-jpa/introduction-jpa-hibernate-spring-data/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/introduction-jpa-hibernate-spring-data/Introduction Every Spring Boot application that touches a relational database eventually encounters three terms used almost interchangeably: JPA, Hibernate, and Spring Data JPA. They are related but distinct, and understanding the difference is essential before writing a single line of mapping code. This article explains what each one is, how they fit together, and why this stack is the dominant approach to Java database access. The Problem: Object-Relational Impedance Mismatch Java applications work with objects: classes, inheritance, collections, references.https://devops-monk.com/tutorials/spring-data-jpa/many-to-many-relationships/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/many-to-many-relationships/Introduction A many-to-many relationship means records in table A can relate to many records in table B, and vice versa. Products have many tags; tags apply to many products. In SQL this requires a join table. In JPA, @ManyToMany and @JoinTable handle this automatically — but when you need extra data on the join (like a creation date or a relevance score), you need a different approach. Simple @ManyToMany: Product and Tag products (*) ──── product_tags ──── (*) tags The product_tags join table has two columns: product_id and tag_id.https://devops-monk.com/tutorials/spring-data-jpa/one-to-many-many-to-one/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/one-to-many-many-to-one/Introduction The one-to-many relationship is the most common in any domain model. An Order has many OrderItems. A Category has many Products. A Customer has many Orders. Understanding @OneToMany and @ManyToOne well — especially bidirectional mapping, collection types, and cascade configuration — is foundational to any JPA application. The Domain Example orders (1) ──────────────── (*) order_items An order has many order items. Each order item belongs to exactly one order.https://devops-monk.com/tutorials/spring-data-jpa/one-to-one-relationships/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/one-to-one-relationships/Introduction A one-to-one relationship means one record in table A corresponds to exactly one record in table B. In JPA this is modelled with @OneToOne. Understanding where the foreign key lives, which side “owns” the relationship, and how cascade operations work is essential before moving to the more complex @OneToMany and @ManyToMany. The Domain Example In the e-commerce system, a Customer has one CustomerProfile containing their preferences and biography. A profile belongs to exactly one customer.https://devops-monk.com/tutorials/spring-data-jpa/optimistic-pessimistic-locking/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/optimistic-pessimistic-locking/The Lost Update Problem Two users edit the same product simultaneously: Time User A User B T1 Load product (price=999) Load product (price=999) T2 Change price to 899 T3 Change price to 799 T4 Save → UPDATE price=899 T5 Save → UPDATE price=799 User A’s change is silently overwritten. This is the lost update problem. Both JPA locking strategies prevent it — in different ways. Optimistic Locking with @Version Optimistic locking assumes conflicts are rare.https://devops-monk.com/tutorials/spring-data-jpa/pagination-sorting/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/pagination-sorting/Why Pagination Matters Returning all rows from a database table is one of the most common production incidents. A query that works in development with 100 rows silently becomes a 10-second, 2 GB memory spike when production has 2 million rows. Pagination limits how many rows travel from the database to the application at a time. Spring Data JPA makes pagination a first-class feature — pass a Pageable to any repository method and get a Page<T> back.https://devops-monk.com/tutorials/spring-data-jpa/primary-keys-generated-values/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/primary-keys-generated-values/Introduction Primary key choice affects performance, scalability, and application design. This article covers every strategy JPA supports — from the simple AUTO_INCREMENT to UUID and composite keys — with the trade-offs of each. IDENTITY Strategy (MySQL AUTO_INCREMENT) GenerationType.IDENTITY delegates key generation to the database column’s auto-increment feature. This is the standard for MySQL. @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; Generated DDL (when ddl-auto=create): id BIGINT NOT NULL AUTO_INCREMENT How IDENTITY works with Hibernate IDENTITY has one important behaviour: Hibernate cannot batch INSERT statements when using IDENTITY.https://devops-monk.com/tutorials/spring-data-jpa/projections-dtos/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/projections-dtos/The Over-Fetching Problem By default, findAll() loads every column for every entity. A Product entity with 20 fields loads all 20 columns — even when a dropdown menu only needs id and name. This wastes bandwidth, memory, and query time. Projections let you define what shape the result should take, and Spring Data JPA generates a query that fetches only those columns. Interface Projections The simplest projection: declare an interface with getter methods matching entity field names.https://devops-monk.com/tutorials/spring-data-jpa/second-level-cache/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/second-level-cache/Cache Layers in Hibernate Hibernate has two cache levels: Level Scope Lifetime Shared? First-level cache One Session (one transaction) Transaction No — per session Second-level cache SessionFactory Application lifetime Yes — across sessions The first-level cache (Article 24) prevents repeated reads within one transaction. The second-level cache prevents repeated reads across transactions — once an entity is loaded, it stays in the shared cache until evicted. When to Use the Second-Level Cache Good candidates:https://devops-monk.com/tutorials/spring-data-jpa/setup-spring-boot-spring-data-jpa/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/setup-spring-boot-spring-data-jpa/Introduction This article builds the project foundation used throughout the entire series. By the end, you will have a running Spring Boot 3.3 application connected to MySQL 8.x with Hibernate 6, a proper connection pool, schema management via Flyway, and SQL logging configured so you can see exactly what Hibernate sends to the database. Project Setup Maven pom.xml <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.https://devops-monk.com/tutorials/spring-data-jpa/specifications-criteria-api/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/specifications-criteria-api/Why Specifications Derived query methods and @Query annotations work for fixed queries. But what happens when the user can filter by any combination of 10 fields — some optional, some not? // Wrong approach — combinatorial explosion List<Product> findByName(String name); List<Product> findByNameAndPrice(String name, BigDecimal price); List<Product> findByNameAndPriceAndCategory(...); // ... you'd need 2^10 = 1024 methods The Specification pattern solves this. Each filter condition is a reusable Specification<T> object. You compose them with and(), or(), and not() at runtime, and Spring Data JPA generates the correct query.https://devops-monk.com/tutorials/spring-data-jpa/testing-spring-data-jpa/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/testing-spring-data-jpa/Why Test JPA Code? Unit tests with mocked repositories verify your service logic but nothing about the database. They won’t catch: Wrong column mapping Constraint violations N+1 queries introduced by a new lazy association Transactions that silently don’t roll back Queries that fail on the real database but pass on H2 Testing against a real database — or at minimum a database-compatible in-memory store — is necessary. Spring Boot’s @DataJpaTest and Testcontainers make this practical.https://devops-monk.com/tutorials/spring-data-jpa/n-plus-one-problem-solutions/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/n-plus-one-problem-solutions/What Is the N+1 Problem? The N+1 problem occurs when loading a list of N entities triggers N additional queries to load their associations — one query per entity. Example: load 50 orders, then access each order’s customer: SELECT * FROM orders; -- 1 query SELECT * FROM customers WHERE id = 1; -- query for order 1's customer SELECT * FROM customers WHERE id = 2; -- query for order 2's customer SELECT * FROM customers WHERE id = 3; -- query for order 3's customer .https://devops-monk.com/tutorials/spring-data-jpa/persistence-context-entity-lifecycle/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/persistence-context-entity-lifecycle/Introduction The persistence context is the single most important concept in JPA. Everything else — lazy loading, dirty checking, transaction scope, detached entity exceptions — only makes sense once you understand what the persistence context is and how it works. Many JPA bugs come from developers not understanding this concept. Understand it well and the rest of JPA becomes predictable. What Is the Persistence Context? The persistence context is an in-memory map of entities managed by the current EntityManager.https://devops-monk.com/tutorials/spring-data-jpa/transaction-boundaries-pitfalls/Mon, 04 May 2026 00:00:00 +0000https://devops-monk.com/tutorials/spring-data-jpa/transaction-boundaries-pitfalls/Transaction Boundaries A transaction boundary is the point where a transaction starts and where it ends. In Spring, boundaries are defined by @Transactional on service methods. HTTP Request └── Controller (no transaction) └── @Transactional Service method ← transaction OPENS here ├── Repository call 1 ├── Repository call 2 └── method returns ← transaction COMMITS here Everything inside the @Transactional method runs in the same database transaction. The persistence context (first-level cache) lives for the duration of that transaction.