Introduction In my previous post I introduced the entity state transitions Object-relational mapping paradigm. All managed entity state transitions are translated to associated database statements when the current Persistence Context gets flushed. Hibernate’s flush behavior is not always as obvious as one might think. Write-behind Hibernate tries to defer the Persistence Context flushing up until the last possible moment. This strategy has been traditionally known as transactional write-behind. The write-behind is more related to Hibernate flushing rather than any logical or physical transaction. During a transaction, the flush may occur multiple times…. Read More
Introduction Hibernate shifts the developer mindset from SQL statements to entity state transitions. Once an entity is actively managed by Hibernate, all changes are going to be automatically propagated to the database. Manipulating domain model entities (along with their associations) is much easier than writing and maintaining SQL statements. Without an ORM tool, adding a new column requires modifying all associated INSERT/UPDATE statements. But Hibernate is no silver bullet either. Hibernate doesn’t free us from ever worrying about the actual executed SQL statements. Controlling Hibernate is not as straightforward as one might… Read More
Introduction Hibernate simplifies CRUD operations, especially when dealing with entity graphs. But any abstraction has its price and Hibernate is no different. I’ve already talked about the importance of fetching strategy and knowing your Criteria SQL queries, but there is more you can do to rule over JPA. This post is about controlling the SQL statement count that Hibernate calls on your behalf. Before ORM tools got so popular, all database interactions were done through explicit SQL statements, and optimizations were mostly targeted towards slow queries. If you think that using Hibernate… Read More
Introduction Criteria API is very useful for dynamically building queries, but that’s the only use case where I’d use it. Whenever you have a UI with N filters that may arrive in any M combinations, it makes sense to have an API to construct queries dynamically, since concatenating strings is always a path I’m running away from. The question is, are you aware of the SQL queries your Criteria API generates behind the scenes? I’ve been reviewing many such queries lately, and I’ve been struck by how easy it is to get… Read More
JOOQ is a neat framework, and it addresses a long-time issue I’ve had with advanced dynamic filtered queries. While Hibernate and JPA come with a useful Criteria API, which I’ve been using for quite some time, there are understandable limits to what you can do with those. For instance, you cannot go beyond simple SQL operations (e.g JOINS, NESTED SLECTS, AGGREGATION) and do something like: window functions, user-defined functions or easy sequencing to name a few. JOOQ doesn’t feel like competing with Hibernate, but instead, I feel like it completes it. I’ve… Read More
Introduction This is the third part of the optimistic locking series, and I will discuss how we can implement the automatic retry mechanism when dealing with JPA repositories. You can find the introductory part here and the MongoDB implementation here.
Introduction Every Java object inherits the equals and hashCode methods, yet they are useful only for Value objects, being of no use for stateless behavior-oriented objects. While comparing references using the “==” operator is straightforward, for object equality things are a little bit more complicated.
Introduction It’s quite common to retrieve a root entity along with its children associations on multiple levels. In our example, we need to load a Forest with its Trees and Branches and Leaves, and we will try to see have Hibernate behaves for three collection types: Sets, Indexed Lists, and Bags.
Introduction When it comes to working with an ORM tool, everybody acknowledges the importance of database design and Entity-to-Table mapping. These aspects get a lot of attention, while things like fetching strategy might be simply put-off. In my opinion, the entity fetching strategy shouldn’t ever be separated from the entity mapping design, since it might affect the overall application performance unless properly designed. Before Hibernate and JPA got so popular, there was a great deal of effort put into designing each query, because you had to explicitly select all the joins you… Read More
Introduction As explained in this article, Hibernate shifts the developer mindset from SQL to entity state transitions. A JPA entity may be in one of the following states: New/Transient: the entity is not associated with a persistence context, be it a newly created object the database doesn’t know anything about. Persistent: the entity is associated with a persistence context (residing in the 1st Level Cache) and there is a database row representing this entity. Detached: the entity was previously associated with a persistence context, but the persistence context was closed, or the… Read More