These requirements are enough to make entities work, but we need additional rules to make them work well: No methods or persistent instance variables of the entity class may be final. The no-arg constructor must be public or protected.Ģ. The entity class may have other constructors as well. The entity class must have a no-arg constructor. The JPA Specification provides its own set of restrictions, here are the two most important to us:ġ. To work, and work well, they need to satisfy certain requirements, let’s start by defining them. Rules for JPA EntitiesĮntities are not regular DTOs. This article will be mostly focused on Hibernate as it is an undoubtable leader among all JPA implementations. Spoiler alert: data classes are not the best option for entity classes. Let’s look at how to avoid the common pitfalls and make the most of using Kotlin.
There is no JPA without entities, and defining them in Kotlin comes with some caveats. Picking JPA for a fresh Kotlin application also makes sense, as it is a mature technology familiar to the developers. Such migrations is one of the reasons why we might have to work with JPA in Kotlin.
The latter allows developers to migrate their projects to Kotlin without having to rewrite the entire codebase. Kotlin is great: it’s more concise and expressive than Java, it allows for safer code and offers seamless interoperability with Java.
0 kommentar(er)
