kotlin-backend-jpa-entity-mapping
Master Spring Data JPA entity design in Kotlin by learning why regular classes outperform data classes for persistence, how to implement stable identity and equality semantics, and when to enforce uniqueness at both database and application layers. Covers fetch strategies, common ORM traps, and Kotlin-specific patterns for preventing N+1 queries and lazy-loading errors.
Kotlin Backend JPA Entity Mapping teaches correct entity design for Spring Data JPA, avoiding data class pitfalls.
AI-generated summary based on this skill's SKILL.md
Install
Kotlin/kotlin-agent-skills/kotlin-backend-jpa-entity-mapping · repository language: Shell
git clone https://github.com/Kotlin/kotlin-agent-skills
cp -r kotlin-agent-skills/skills/kotlin-backend-jpa-entity-mapping ~/.claude/skills/kotlin-backend-jpa-entity-mappingnpx skillfed install Kotlin/kotlin-agent-skills/kotlin-backend-jpa-entity-mappingFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
Why are Kotlin data classes problematic for Spring Data JPA entities?
kotlin-backend-jpa-entity-mapping recommends regular classes over data classes for JPA entities because data classes auto-generate equals(), hashCode(), and toString() based on all properties. This breaks entity identity semantics: two entities with identical field values become equal even if they represent different database rows. Data class copy() also creates new instances, corrupting Hibernate's identity map. Use regular classes with explicit, stable equals/hashCode implementations tied to the entity's database identifier instead.
How do you fix N+1 query problems in kotlin spring data jpa?
kotlin-backend-jpa-entity-mapping addresses N+1 queries through explicit fetch strategies: use @EntityGraph to eagerly load related entities in a single query, apply fetch = FetchType.EAGER selectively for small collections, or use JOIN FETCH in JPQL. Lazy-load only when necessary and batch-fetch with spring.jpa.properties.hibernate.default_batch_fetch_size. Monitor query logs and prefer DTO projections for read-heavy operations to avoid loading full entity graphs unnecessarily.
What's the correct way to implement identity and equality in Kotlin JPA entities?
kotlin-backend-jpa-entity-mapping emphasizes that JPA entity identity must be based on the database identifier, not all fields. Override equals() to compare only the @Id field (or composite key), and hashCode() to derive from the same identifier. This ensures entities remain equal across session boundaries and collection operations. Implement equality before the entity is persisted by using a business key or generating IDs early. Never use mutable fields in equals/hashCode calculations.
How does kotlin-backend-jpa-entity-mapping handle bidirectional relationships?
kotlin-backend-jpa-entity-mapping teaches that bidirectional relationships require careful synchronization: maintain both sides manually in setter methods, use mappedBy on the inverse side to prevent duplicate foreign keys, and apply cascade and orphanRemoval judiciously. Kotlin's nullable types help model optional sides. Avoid lazy-loading the inverse side unless fetched explicitly; use @EntityGraph or JOIN FETCH. Always initialize collections as mutable sets or lists in the constructor to prevent NullPointerException during Hibernate initialization.
What Kotlin-specific ORM traps should you avoid in entity design?
kotlin-backend-jpa-entity-mapping warns against: using immutable val properties (Hibernate needs mutable fields), relying on default parameter values in constructors (breaks reflection), storing non-entity objects in collections without proper converters, and assuming Hibernate proxies behave like real instances (they fail instanceof checks). Avoid lateinit for lazy-loaded associations; use nullable types instead. Never override equals/hashCode in a way that triggers lazy loading, as this causes LazyInitializationException outside active sessions.
How should you optimize fetch plans to prevent lazy initialization exceptions?
kotlin-backend-jpa-entity-mapping recommends using @EntityGraph or @NamedEntityGraph to define fetch plans declaratively, ensuring related entities load within the transaction. Apply @Transactional on service methods to keep sessions open during data access. For read-only queries, use DTO projections with constructor expressions to load only needed fields. Configure spring.jpa.open-in-view cautiously—it masks lazy-loading issues. Batch-fetch collections with Hibernate hints to reduce query count while maintaining explicit control over what loads.
SKILL.md
rendered from the published skill — quoted content, verbatim
JPA Entity Mapping for Kotlin
Kotlin's data class is natural for DTOs but dangerous for JPA entities. Hibernate relies on
identity semantics that data class breaks: equals/hashCode over all fields corrupts
Set/Map membership after state changes, and auto-generated copy() creates detached
duplicates of managed entities.
This skill teaches correct entity design, identity strategies, and uniqueness constraints for Kotlin + Spring Data JPA projects.
Entity Design Rules
- Never use
data classfor JPA entities. Use a regularclass.
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 1 file
skills/kotlin-backend-jpa-entity-mapping/SKILL.md