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 wanted to select from, and all the columns you were interested in. And if that was not enough, the DBA would optimize the slow running queries.

In JPA times, the JPQL or HQL queries are fetching Entities along with some of their associated relationships. This eases development, as it frees us from manually choosing all table fields we are interested in, and sometimes joins or additional queries are automatically generated for serving our needs.

This is a double-edged sword. On one hand, you can deliver features faster, but if your automatically generated SQL queries are not efficient, your overall application performance might suffer significantly.

Had this problem this morning fixed from stackoverflow than found this. Thx Vlad Mihalcea for a concise explanation to speed up development & production issues !!!
Hibernate fetching strategies - using #JPA and @Hibernate @vlad_mihalcea https://t.co/Dwf1ZPPpV0

— Gal Levinshtein (@gkodkod) September 17, 2018

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 entity was manually evicted.
• Removed: the entity was marked as removed and the persistence context will remove it from the database at flush time.

Moving an object from one state to another is done by calling the EntityManager methods such as:

• persist
• merge
• remove

Cascading allows propagating a given event from a parent to a child, also easing managing entities relationship management.

During the flush time, Hibernate will translate the changes recorded by the current Persistence Context into SQL queries.

Read More

Introduction

Hibernate is a great ORM tool, and it eases development considerably, but it has a lot of gotchas you must be aware of if you want to use it properly.

On medium to large projects, it’s very common to have bidirectional parent-child associations, which allow us to navigate both ends of a given relationship.

When it comes to controlling the persist/merge part of the association, there are two options available. One would be to have the @OneToMany end in charge of synchronizing the collection changes, but this is an inefficient approach.

The most common approach is when the @ManyToOne side controls the association and the @OneToMany end is using the “mappedBy” option.

I will discuss the latter approach since it’s the most common and the most efficient one, in terms of the executed queries number.

Read More