Every entity query, be it JPQL or Criteria API, needs to be parsed and compiled to an AST (Abstract Syntax Tree) in order to generate the associated SQL query. The entity query compilation takes time, as explained in this article so Hibernate provides a
QueryPlanCache to store already-compiled plans.
Starting with Hibernate 5.4, the Hibernate
Statistics object allows you to monitor the Query Plan Cache and this article will show you how to take advantage of this feature to speed up IN query performance.
In this article, you are going to learn why overwriting entity collections is an anti-pattern and how you can merge collections both effectively and efficiently with JPA and Hibernate.
As explained in this article, JPA 2.2 supports
OffsetDateTime from the
java.time package. Hibernate has been supporting the Java 8 Date/Time classes since 5.0 via the
hibernate-java8 dependency, but since version 5.2, this dependency was merged with
hibernate-core so you get the
ZonedDateTime types in addition to the ones supported by JPA 2.2.
However, neither JPA nor Hibernate supports the
java.time.Year type out-of-the-box. As you will see, adding support for
java.time.Year is very easy with both standard JPA or Hibernate.
In this article, we are going to see how you can map a
java.time.YearMonth with both JPA and Hibernate.
As I explained in this article, JPA 2.2 supports the following Date/Time types introduced in Java 8:
Apart from supporting those, Hibernate supports also:
However, neither JPA nor Hibernate support the
java.time.YearMonth out-of-the-box. As you will see, adding support for
java.time.YearMonth is really straightforward for both standard JPA or Hibernate.
Inspired by this StackOverflow answer I gave recently, I decided it’s time to write an article about query pagination when using JPA and Hibernate.
In this article, you are going to see how to use query pagination to restrict the JDBC
ResultSet size and avoid fetching more data than necessary.