The Hi/Lo Algorithm in Hibernate: Optimizing Database Identifier Generation

How to Define an Index with Spring Data JPA

In this article, we will deal with the definition of indexes in Spring Data JPA and the Hibernate Framework. Our focus is on defining an index for a non-primary key and using the @Index annotation.

The proper use of indexes plays a crucial role in optimizing the performance of your database, as they enable faster data queries and overall improve database performance.

Defining an Index with the @Index Annotation

With JPA and Hibernate, you can define indexes on entities and non-entity tables such as @SecondaryTable, @CollectionTable, and @JoinTable using the @Index annotation. This serves to optimize database performance and customization.

Marcus Held

Accessing Non-Final Property Name in Constructor With JPA

The implications of JPA always manage to surprise me. Yesterday a colleague of mine made me aware of a warning in IntelliJ. The conversation went like that: “Marcus, in your blog you explained that we should check constraints in the constructor instead of bean validation . Me: “yeah”. “I wanted to make it right, but when I do it in this entity IntelliJ warns me with Accessing non-final property name in constructor”. So I dug into it. Fearing my conclusion would change the recommendation that I gave in (k)lean JPA two years ago.

Marcus Held

Prefer UUID for your Primary Key

In my last post I discussed the downsides of using numerical types for the primary key of an entity. We should avoid these issues all together by using UUID instead and in this post I will discuss the up- and downsides of this approach.

Using a UUID as the primary ID is simple:

@Entity
class Flat(
    @Id
    val id: UUID = UUID.randomUUID()
)

Generate the ID on the application

Similar to numerical ids we can generate it on the database as well. But for UUID this is not necessary. The reason we did this in the first place is that we needed to make sure that an ID is not used twice. A collision of UUID is very unlikely to occur.

Marcus Held

The Inevitable Consequence of a Numerical Id

In many (JPA) applications numerical ids are chosen for the surrogate key of the entities. But how do we make sure that they are not used twice? In a scenario where our application needs to scale horizontally we need a solution for that. Most developers come to the conclusion that the database should take care of that. But this is a fragile solution and in this article I want to discuss it.

Marcus Held

Should I Pass JPA Entities as Method Parameters?

JPA entities have a couple of pitfalls and consequences when handling them in your application. Especially understanding how JPA manages and synchronizes the state of an entity is essential to avoid unexpected behavior. This can be unintuitive when passing JPA entities as method parameters in Spring Data in- and outside a transaction. In this post I will explain a best practice when working with JPA entities and when it’s okay to pass it through method parameters and when you should avoid it.

Marcus Held