When executing an entity query (e.g. JPQL, HQL or Criteria API), you can use any SQL function without having to register it as long as the function is passed directly to the WHERE clause of the underlying SQL statement.
However, if the SQL function is used in the SELECT clause, and Hibernate has not registered the SQL function (be it a database-specific or user-defined function), you will have to register the function prior to using it in an entity query.
In this article, you are going to learn various ways to register SQL functions with JPA and Hibernate.
Continue reading “The best way to use SQL functions in JPQL or Criteria API queries with JPA and Hibernate”
Every JPQL query must be compiled prior to being executed, and, because this process might be resource intensive, Hibernate provides a
QueryPlanCache for this purpose.
For entity queries, the query
String representation is parsed into an AST (Abstract Syntax Tree). For native queries, the parsing phase cannot compile the query, so it only extracts information about the named parameters and query return type.
Continue reading “A beginner’s guide to the Hibernate JPQL and Native Query Plan Cache”
While doing my High-Performance Java Persistence training, I realized that not all developers are familiar with the
getReference method of the JPA
EntityManager and most of them use
find almost exclusively.
In this article, we are going to see the difference between the
getReference method so that it’s clear when to apply them depending on the underlying use case.
Continue reading “How do find and getReference EntityManager methods work when using JPA and Hibernate”
Traditionally, both MySQL and MariaDB relied on AUTO_INCREMENT columns to generate an IDENTITY Primary Key. Although IDENTITY columns are very efficient in generating the Primary Key value, when it comes to using JPA and Hibernate, the IDENTITY generator prevents us from using JDBC batch inserts.
To automatically enroll multiple INSERT, UPDATE or DELETE statements, Hibernate requires delaying the SQL statement until the Persistence Context is flushed. This works very well for the SEQUENCE identifier since the entity identifier can be fetched prior to executing the INSERT statement.
However, for IDENTITY columns, the only way to know the entity identifier is if we execute the SQL INSERT statement. And, Hibernate needs the entity identifier when persisting an entity because otherwise, it cannot build the key which is used for locating an entity in the currently running Persistence Context.
Continue reading “MariaDB 10.3 supports database sequences”
Recently, I stumbled on the following Twitter thread:
This jOOQ feature is indeed really useful since it reduces the number of SQL statements that have to be generated when varying the IN clause parameters dynamically.
Starting with Hibernate ORM 5.2.18, it’s now possible to use IN clause parameter padding so that you can improve SQL Statement Caching efficiency.
In this article, I’m going to explain how this new mechanism works and why you should definitely consider it when using a relational database system which supports Execution Plan caching.
Continue reading “How to improve statement caching efficiency with IN clause parameter padding”