Hibernate search policy and Hibernate search policy

Hibernate search policy and Hibernate search policy

The session in hibernate loads a persistent object according to load () and get () according to the parameter formulation OID (ObjctID. In addition, the Query. list () method loads persistent objects according to HQL statements.

The above methods can be used to load persistent objects of hibernate. If you have any friends who do not understand the "temporary State", "Free State", "persistent State", and "delete state" of the hibernate object, you should first learn about it.

For the above Retrieval Strategies of hibernate, let's first take a look at several of their work details.

The first is the load () method of the session. Let's take the example of Customer and Orders for a simple explanation. The relationship between MERs and Orders is one-to-many. We assume that we have configured one-to-many unidirectional associations between the two objects hbm. xml.

I. session load (MERS MERs. class, new Long (1) returns a reference to a Customer persistence object. At this time, the Customer has not been initialized. Because SQL query statements are not executed at this time. Initialization is performed only when the Customer is used. That is, execute the query statement. In this case, if you configure

1 <set
2 name = "orders"
3 insever = "ture"
4 lazy = "true"

5 fetch = "select"

6 <one-to-learn class =...>
7>

The default attribute of lazyd is true, that is, lazyd is used for lazyd loading.

1. If lazy is set to false, all the Orders objects of Customers will be queried when the Customers object is initialized. This is also called Instant retrieval. It is worth noting that if the fecth attribute is set to join in the set label above, when load is actually executing the query, when associating objects, the left outer join query is urgently used. In this way, even explicitly setting lazy attributes is meaningless. As for why, all I want to know about SQL queries know the reason. Of course, the fecth attribute has other options, such as select, subselect, and fetch. The default value is select.

2. If lazy is set to true, only the MERs object will be queried during Customers initialization. The Orders object associated with MERs Mers is queried only when the Orders attribute is actually used. For example, if Order order = customer. iterator (). next () is iterated, the proxy instance of Orders is returned. At this time, the Order has not been instantiated, so no SQL query is performed. It is instantiated only when its attribute or method is called, for example, Order number: Order. getOrderNo.

Lazy also has other options for extra enhancement. For example, when you obtain the size/contains of an order set, the orders will not be initialized, but an SQL statement will be sent to the database to query and obtain the value, the database can be instantiated and queried only when the set element value is actually used. The difference between this clever method and lazy setting to true is that extra is more "lazy" and more delayed when lazy loading is selected.

Ii. session. get (Customers. class, new Long (1 )). Get uses an immediate retrieval policy. Here, MERS MERs will initialize it immediately.

1. If set lazy to true in the Orders configuration, it is similar to load. SQL join queries are performed only when the attributes of Orders are actually used.

2. If lazy is set to false, all associated objects of Orders will be initialized immediately during the get () method execution. The only difference between this method and the first method of load is that load Initialization is later than the time when get initializes MERs, and it is more delayed.

Note that if the fecth attribute is set to join in the set label above, the join object is urgently used for left outer join query. Whether or not lazy is set to true, the load is immediately used.

3. list () method in the query interface. Seesion. createQuery (SQL). list (). After this method is executed, the program sends an SQL statement to the database to perform the query operation.

1. If lazy is set to true in the configuration of Orders, SQL join queries will be performed only when the attributes of Orders are actually used.

2. If lazy is set to false, all associated objects of Orders will be initialized immediately. This is similar to the get () method.

Note that in query. list (), it will fetch the join policy, so even if you explicitly set fetch to join, it will not use the urgent left outer join query.

To sum up the differences between the load, get, and query. list methods:

1. load has a "delay" effect on the loading of objects at the class level, while get and query. list adopt the immediate retrieval policy.

2. When associating a one-to-Multiple Association, load adopts the same policy as get and query. list, provided that the lazy loading method on the worker side is the same.

3. The fetch policy is consistent during get and load loading. Query. list ignores the join policy of fetch.

The lazy loading policy for one-to-many one-way associations is roughly analyzed. In fact, two-way is also very easy to understand.

Assume that the following configuration is configured in <Orders-to-one> in the Orders. hbm. xml file:

1 <allow-to-one

2 insever = "true"
3 lazy = "proxy"
4 ....
5 class = "..."

6/>

The premise is that the set inserver in the Customers. hbm. xml file is set to false or not explicitly set. The default value is false.

1. When loading the orders object, if the lazy method used by customer is proxy, the lazy method is used. That is to say, only when orders obtains its custormer attribute can it load the associated customer object. If order lazy adopts the lazy loading method, the orders object is not obtained when the customer is obtained.

For example, in get (orders. class, new Long (1) method to obtain Orders, it will immediately load the Orders object, when getting Orders. getCustomer (). when getName () is used, it loads the Customer object, and if it obtains the Orders under the Customer object, it loads the Orders. That is to say, three SQL statements are executed, and one SQL statement is executed each time.

If the value of lazy is false for Orders, it is not used above. The Orders object will be loaded immediately, and then the Orders object will be loaded together when Customers is loaded. That is to say, three SQL statements will be executed here, but they will be executed twice. The first query is orders, and the second query is two. The query is performed to query the Customer and Orders.

2. If the lazy method used by the customer is no-proxy, it is proved that non-proxy loading is used. The difference between this method and the above is that after loading the Orders, only the Customers instance is returned when the customer attribute is obtained, rather than the proxy instance. This will immediately instantiate MERs. Others are consistent with those of the proxy. That is to say, the difference lies in the different policies for delayed loading of MERs objects.

3. the lazy option can also be false. When loading Orders, the Customers will be immediately searched. That is to say, three SQL statements will be issued. Query order twice, and query customer once.

For the lazy loading of hibernate, only one-to-many association code is involved here, but it should be understandable. There is also one-to-many, one-to-one, and many-to-many .. Hibernate has its own policies and is flexible. We will make up for you later.