Shulou(Shulou.com)06/02 Report--

This article focuses on "what are the Hibernate inheritance mapping strategies". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn what the Hibernate inheritance mapping strategy is.

There are three strategies for Hibernate inheritance mapping.

Hibernate supports three basic inheritance mapping strategies:

◆ one table per class hierarchy (table per class hierarchy)

One table for each subcategory of ◆ (table per subclass)

One table for each specific class of ◆ (table per concrete class)

In addition, Hibernate supports a fourth slightly different polymorphic mapping strategy:

Implicit polymorphism (implicit polymorphism)

For different branches within the same inheritance level, different mapping strategies can be adopted, and then implicit polymorphism can be used to complete polymorphism across the whole level. However, under the same root element, Hibernate does not support mappings that mix elements, and. Under the same element, you can mix "one table per class hierarchy" (table per hierarchy) and "one table per subclass" (table per subclass), which is achieved by combining the sum of elements (see later).

1. One table for each class hierarchy (Table per class hierarchy)

Suppose we have the interface Payment and its implementation classes: CreditCardPayment, CashPayment, and ChequePayment. The mapping code for "one table per class hierarchy" (Table per class hierarchy) is as follows:

......

Only one table is needed to adopt this strategy. It has a big limitation: fields defined by subclasses, such as CCTYPE, cannot have NOT NULL constraints.

two。 One table for each subcategory (Table per subclass)

For the classes in the above example, the mapping strategy of "one table for each subclass" is adopted, and the code is as follows:

......

I need four forms. The three subclass tables are associated to the superclass table through the primary key (so the relational model is actually an one-to-one association).

3. One table for each subcategory (Table per subclass), using discriminator (Discriminator)

Note that for the "one table per subclass" mapping strategy, the implementation of Hibernate does not need to identify fields, while other object / relational mapping tools use a different implementation than Hibernate, which requires a type discrimination field (type discriminator column) in the superclass table. The approach taken by Hibernate is more difficult to implement, but from a relational (database) point of view, it is arguably more correct. If you prefer to use the "one table per subcategory" strategy with identification fields, you can use it in conjunction with, as follows:

......

The optional declaration fetch= "select" is used to tell Hibernate not to use external joins (outer join) to grab the data of the subclass ChequePayment when querying the superclass.

4. Mix "one table per class hierarchy" and "one table per subclass"

You can even mix the strategies of "one table per class hierarchy" and "one table per subclass" in the following ways:

...

For any of the above mapping strategies, the association to the root class Payment is mapped using.

5. One table for each specific category (Table per concrete class)

There are two approaches to the mapping strategy of "one table for each specific class". * the method is to use.

......

Three tables are involved here. Each table defines the corresponding fields for all properties of the corresponding class, including those inherited from the superclass.

The limitation of this approach is that if an attribute is mapped in a superclass, its field name must be the same as that defined in all subclass tables. (we may relax this restriction in subsequent releases of Hibernate.) The identity generator strategy (identity generator strategy) is not allowed in the inheritance hierarchy of the federated subclass (union subclass). In fact, the primary key seed of the primary key has to be shared by all the federated subclasses in the same inheritance hierarchy.

6. Table per concrete class, using implicit polymorphism

Another alternative is to use implicit polymorphism:

.........

Note that we don't explicitly mention the interface Payment anywhere. Also notice that the attributes of Payment are mapped in each subclass. If you want to avoid repetition, consider using XML entities (for example, [] in the DOCTYPE declaration and & allproperties; in the mapping).

The drawback of this approach is that SQL statements with UNION cannot be generated when Hibernate executes polymorphic queries (polymorphic queries).

For this mapping strategy, it is usually used to implement polymorphic association mapping to Payment.

7. Implicit Polymorphism mixed with other inheritance Mappings

There is one more thing to note about this mapping. Because each subclass is mapped in its own independent element (and Payment is just an interface), each subclass can easily become part of another inheritance system! (you can still use polymorphic queries on the interface Payment.)

......

We still haven't explicitly mentioned Payment. If we perform queries against interface Payment-- for example, from Payment-- Hibernate automatically returns instances of CreditCardPayment (and its subclasses, because they also implement interfaces Payment), CashPayment, and Chequepayment, but does not return instances of NonelectronicTransaction.

At this point, I believe you have a deeper understanding of "what is the Hibernate inheritance mapping strategy?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.