Hibernate implements JPA’s standardized constructor expressions and @SqlResultSetMappings to map the results of your queries. And it also supports proprietary ResultTransformers. They provide a powerful and flexible way to map the result of your JPQL, Criteria, and native SQL query to a specific object structure. This can be entity or DTO objects, java.util.List or java.util.Map
For the last 2 years, I have shared a list of the Java-related YouTube channels that I find the most enjoyable or useful. And based on the popularity of these articles, it seems like I’m not the only one who enjoys watching good lectures and conference talks on YouTube. That’s especially the case in the
You probably learned that you should use FetchType.LAZY for all of your associations. It ensures that Hibernate initializes an association when you use it and doesn’t spend any time getting data you don’t need. Unfortunately, this introduces a new issue. You now need to use a JOIN FETCH clause or an EntityGraph to fetch the
EntityGraphs and JOIN FETCH clauses provide an easy and efficient way to fetch an entity and initialize its associations. But if you try to use it with a domain model that uses inheritance, you will quickly run into an issue: You can’t use this approach in a polymorphic query to fetch an association that’s defined
Spring Boot and Spring Data JPA make the handling of transactions extremely simple. They enable you to declare your preferred transaction handling and provide seamless integration with Hibernate and JPA. The only thing you need to do is to annotate one of your methods with @Transactional. But what does that actually do? Which method(s) should
The LazyInitializationException is one of the most common exceptions when working with Hibernate. There are a few easy ways to fix it. But unfortunately, you can also find lots of bad advice online. The proclaimed fixes often replace the exception with a hidden problem that will cause trouble in production. Some of them introduce performance
For quite some time, finding the right scope of a microservice was proclaimed to solve all problems. If you do it right, implementing your service is supposed to be easy, your services are independent of each other, and you don’t need to worry about any communication between your services. Unfortunately, reality didn’t hold up to
Since I started talking about microservices and the challenges that you have to solve whenever you want to exchange data between your services, I hear 3 things: You only need to model the scope of your services “the right way” to avoid these problems. We use multiple local transactions, and everything works fine. It’s really
Page [tcb_pagination_current_page] of [tcb_pagination_total_pages]