Hibernate crawling policy and lazy loading

The scope and function of the capture policy application:

This function is mainly used to operate on the underlying SQL statements of hibernate when a set object extracts data, that is, the mechanism by which an object queries associated objects and sends SQL statements.

Take Students and classes as an example:

Capture policy:
1. The main research is how to extract data from set sets.
2. In the Classes. hbm. xml file

Join left Outer join
This policy does not work if you want to translate SQL statements into analytics and subqueries.
Select default
First query one end, then query multiple ends
Subselect subquery
If you need to analyze and translate into SQL statements that have subqueries, this policy is the most efficient.

Example:

/*** Query all students in all classes * solution: subquery fetch = "subselect" * // @ Test public void testAll_Classes () {Session session = sessionFactory. openSession (); List
 
  
CList = session. createQuery ("from Classes"). list (); for (Classes classes: cList) {Set
  
   
Students = classes. getStudents (); for (Student student: students) {System. out. println (student. getSname () ;}} session. close ();}
  
 

Corresponding class ing file configuration

Corresponding SQL statement output by hibernate

Hibernate:     select        classes0_.cid as cid0_,        classes0_.cname as cname0_,        classes0_.description as descript3_0_     from        Classes classes0_Hibernate:     select        students0_.cid as cid0_1_,        students0_.sid as sid1_,        students0_.sid as sid1_0_,        students0_.sname as sname1_0_,        students0_.description as descript3_1_0_,        students0_.cid as cid1_0_     from        Student students0_     where        students0_.cid=?

When the configuration file is changed

The output SQL statement is:

Hibernate:     select        classes0_.cid as cid0_,        classes0_.cname as cname0_,        classes0_.description as descript3_0_     from        Classes classes0_Hibernate:     select        students0_.cid as cid0_1_,        students0_.sid as sid1_,        students0_.sid as sid1_0_,        students0_.sname as sname1_0_,        students0_.description as descript3_1_0_,        students0_.cid as cid1_0_     from        Student students0_     where        students0_.cid=?

The subquery column does not exist:

@ Test/*** query all students whose class number is 1 */public void testQueryClasses_Id () {Session session Session = sessionFactory. openSession (); Classes classes = (Classes) session. get (Classes. class, 1L); Set
 
  
Students = classes. getStudents (); for (Student student: students) {System. out. println (student. getSname ();} session. close ();}
 

The configuration file is: the output SQL statement is:

Hibernate:     select        classes0_.cid as cid0_0_,        classes0_.cname as cname0_0_,        classes0_.description as descript3_0_0_     from        Classes classes0_     where        classes0_.cid=?Hibernate:     select        students0_.cid as cid0_1_,        students0_.sid as sid1_,        students0_.sid as sid1_0_,        students0_.sname as sname1_0_,        students0_.description as descript3_1_0_,        students0_.cid as cid1_0_     from        Student students0_     where        students0_.cid=?

The configuration file is: SQL statement:

Hibernate:     select        classes0_.cid as cid0_1_,        classes0_.cname as cname0_1_,        classes0_.description as descript3_0_1_,        students1_.cid as cid0_3_,        students1_.sid as sid3_,        students1_.sid as sid1_0_,        students1_.sname as sname1_0_,        students1_.description as descript3_1_0_,        students1_.cid as cid1_0_     from        Classes classes0_     left outer join        Student students1_             on classes0_.cid=students1_.cid     where        classes0_.cid=?

Generally, the fewer SQL statements, the higher the performance.

About lazy loading:

When the data volume in the set to be retrieved is large, we use lazy loading, that is, when we need to use this object, it is loaded from the database, that is, when student is used. the session is loaded only when getXxx () or other methods are used. the get () method is not loaded.

Lazy Loading
1. Class lazy loading
1. The session. load method can be used to generate proxy objects.
2. When the session. load Method is executed, no SQL statement is issued.
3. Issue an SQL statement when obtaining its general attributes
4. valid only for general attributes and invalid for the Identifier attributes
5. By default, the load is lazy.
2. Set lazy loading
False: When session. get is used, the set is loaded.
True: It is loaded only when the set is traversed.
Extra
Perform count, min, max, sum, and other operations on the set.
3. Single-end associated lazy loading (Multiple-to-one)
No-porxy default value true
Load one end Based on Multiple ends, and there is only one data, so it doesn't matter.


Conclusion: lazy loading mainly solves one problem: Class, set, and feature-to-one issue SQL statements and load data.