Code-Held

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.

In recent reviews I stumbled upon extension functions which didn’t quite felt right, but I wasn’t able to determine where that gut feeling was coming from. After seeing quite a lot of them I came to some conclusions why that’s the case, and I gathered rules for me when extension functions make sense to use and when they should be avoided. I discovered an overuse of the language feature - something you often experience when you work with a new fancy language with nice features. In this post I’ll share my thoughts.

This week I was taught again that you should be thoughtful when applying patterns you read on the internet (which is ironic - because the same applies to this post ;-) ). This time colleagues heavily applied the Creational Design Patterns in Kotlin: Builder from Baeldung. Using the builder pattern in Kotlin in this example is an anti-pattern and in this post I will reason why you’ll end up with safer, less error-prone and less boilerplate when properly applying Kotlins language features instead of this builder pattern.

When working with JPA I prefer generating the primary key on the application and not in the database (check out this post from James Brundege). Additionally, I also prefer optimistic locking and in order to use it you need to specify a @Version field in your Entity. But you need to be careful how to initialize these two fields. In this post I’ll talk about an error when you assign a default value for both fields in JPA which leads the EntityManager to never call persist but the merge operation instead when creating a new entity.

Last week I reviewed the data design of a colleague. He had to improve a feature and while working on it he noticed that the existing design was not sufficient to properly reflect the changes he had to do. Intuitive he followed the practices of other models in the code and introduced an enumeration to distinguish between different alert types that can be created in the application. Using an enumeration for it is not the optimal solution and in this post I want to describe why you should always question when you see an enumeration in your code and think about solving it with polymorphism instead.

In a project I worked on I saw that nearly every entity and value object was created with Lomboks @Builder. Their reason is that it makes it easier to construct these objects - especially for tests. But it comes with a cost. The problems that these builders create can’t be detected by the compiler and are especially dangerous in every CI environment.