When adding/removing entities to/from a collection in Hibernate one may easily run into annoying TransientObjectException or TransientPropertyValueException exceptions. This blog uses a simple example to describes how to avoid these issues.

A common practice with Hibernate is to give each entity an id field to store its primary key. This field is generally managed by Hibernate. When the entity has not been saved yet, the field is null, which is also how Hibernate detects the object has not been saved yet. Once it is saved, Hibernate sets the value of the id to the generated value. Since the value of the id field changes, it is not suited to base your equals and hashCode methods on. Which is a bit counter-intuitive, because it corresponds to the primary key in the database. The solution is to use Business Keys.

How to represent datetimes in APIs, the code, and the database is always tricky. Most people I have worked with struggled with this. The main mistake is omitting the time zone based on the false assumption that defaults are uniform across systems. They are not. As a result timestamps carried across systems get weird time jumps. This blog gives some rules to avoid these mistakes and gives a clean set up.

Hibernate is a great Object Relational Mapping (ORM) library for accessing data in a relational database. It is one of the leading implementations of Java Persistence (formerly known as JPA). Using JPQL (based on HQL, which is still a nice syntax guide) one can access and update the data in the database through your ORM objects in a simplified SQL way. However, when implemented incorrectly one can run into serious performance problems. They can all be avoided though. Here are some important things to consider to make your queries performant.