Clarifying terminology - What does "hydrating" a JPA or Hibernate entity mean when fetching the entity from the DB

In the context of ORM / Lazy loading of entities, my understanding of the term "Hydration" is as follows:

"Hydrating" describes the process of populating some or all of the previously unpopulated attributes of an entity fetched using lazy loading.

Eg: class Author is loaded from the database:

@Entity
class Author
{
     @Id
     long id;
     List<Book> books;
}

Initially, the books collection is not populated.

It is my understanding that the process of loading the books collection from the database is referred to as "Hydrating" the collection.

Is this definition correct, and is the term common place? Is there another more common term I should be using for this process?

Hydrate began as a term for populating an instantiated (but empty) value-object/model from a db, (specifically in Hibernate.)

Various other ORMs and tools like BizTalk use Hydrate and other related terminology, (e.g. BizTalk uses the term Dehydrated to mean an instance is available but not yet populated.)

Personally I'm averse to redundant terminology overhauls, populated means the same thing, without re-inventing language. It adds nothing and leads to confusion (common first thought on encountering re-invented terms: is this somehow different and magical?).

The BizTalk extension of this style of language, specifically Dehydrated is redundant. I expect people haven't forgotten how to say, empty, or clear?

Hydrated and its related metaphors are essentially marketing tools, invented to differentiate Hibernate from competing products.

At this point Hibernate and other ORM products have used these terms for many years, so Hydrate (and Dehydrate) are here to stay.

Entity loaded state

When you are fetching an entity, Hibernate will try to load it either from the second-level cache or the database.

If the entity is not stored in the second-level cache, then a query is executed and the JDBC ResultSet is transformed into an Object[] that contains the loading-time entity property values.

The second-level cache stores this Object[] when caching an entity. So, when loading an entity either from the DB or the second-level cache, you will get the Object[] entity property value array.

The process of transforming the Object[] loaded state into a Java entity object is called hydration, and it looks as follows:

final Object[] values = persister.hydrate(
    rs, id, object,
    rootPersister, cols, eagerPropertyFetch, session
);

The loaded state is saved in the currently running Persistence Context as an EntityEntry object, and it will be used later for the default dirty checking mechanism, which compares the current entity data against the loading-time snapshot.

The loaded state is also used as the cache entry value for the second-level entity cache.

The inverse operation of transforming the entity to an Object[] that's used when binding SQL parameter values for INSERT, UPDATE or DELETE statements is called dehydration.

hydration is a loose term. In our company we use "rehydration" as he term to load all the object properties of an entire object graph. Here is a post that talks about various levels of hydration (again this is a general usage though they are using in the context of hibernate).

I think the term 'hydrate(s)' in the context of ORM simply means the framework gives you objects. So the objects are 'hydrated' by the ORM after the data is pulled from the store. The term can be applied anytime an ORM framework gives you an object/graph that is represented in the store.