澄清术语——当从数据库获取实体时，“水合”JPA 或 Hibernate 实体意味着什么

在 ORM/Lazy 实体加载的背景下，我对术语“水合作用”的理解如下:

“ Hydrating”描述了使用延迟加载获取的实体的部分或全部以前未填充的属性的填充过程。

例如: 类 Author是从数据库加载的:

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

最初，没有填充 books集合。

我的理解是，从数据库加载 books集合的过程被称为“水合作用”的集合。

这个定义正确吗? 这个术语是常见的地方吗？对于这个过程，我是否应该使用另一个更常见的术语？

35878 次浏览
小开

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.

小开
最佳答案

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.

小开

the term hydration is extensively used in the guts of the hibernate library to refer to the process of setting the fields of a recently loaded object, and is indeed related to the object graph populaton.
but it's different than the concept of lazy loading, that is, giving the user a half-filled object and letting the rest be loaded on demand.
the hydration is always performed, lazily or eagerly and it's hibernate stuff.
lazy loading is just for convenience

replace hibernate with the name of your orm of choice

小开

Entity loaded state

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

Entity loaded state

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 general ORM domain term meaning a method by which the query result is returned. It's not a process, not a verb, not an action or event that occurs but a noun. Therefore to hydrate simply means to use a hydration method. Hydration method creates a structure that represents data. There's a popular misconception, though, that every hydration not only instantiates an object but also populates it before returning its reference. That's not a rule. While a specific hydration can also populate an object, not all hydrations do that. Different hydrations return different structures:

  • singular scalar
  • array of scalars
  • array of arrays
  • array of objects
  • object collecting scalars
  • object collecting arrays
  • object collecting other objects
  • ...more

It's an ORM implementation detail. Some ORMs provide multiple hydrations and you can choose one by passing an argument to query builder, some don't give you that control and replace it by convention trying to be smart about it (which is the source of the hydration/population misconception mentioned above). More advanced ones allow you to write your own hydrators for custom objects that can map field types. The term itself is closely related to deserialization (which is more general and doesn't necessarily involve a database or an ORM).


提交答案