dealing with association relationships is a common operation in Orm, especially when querying for an entity, it is often necessary to query the entity associated attributes, such as querying the user for cascading query role information, and possibly the role and the query permission information. There are a number of ways to accomplish this in hibernate:
1. Configure the Opensessioninviewfilter, let the session in the view layer to save open state, can be used at any time, this seems to be a once and for all, but it also brings some problems, as to what will be the question Baidu will give you the answer.
2. When mapping the entity to set the association property lazy= "False", indicating that the association is not lazy loading, so that the entity Association properties will be queried together, this way is sometimes feasible, but the biggest problem is inflexible, one but the configuration lazy= "false", Sometimes you don't want the Entity association property to be queried together.
3. A "fetch" keyword is provided in hql, whose literal meaning is "crawl", which gives you the flexibility to crawl the properties we want to query for entity associations. For example: Querying the user Fetch role: from user U left join fetch u.roles RS WHERE ..., if the role also has to crawl the limit, then: from the user U-bound join fetch U.roles RS LEFT JOIN FETCH rs.privileges PS WHERE ...
Fetch is very flexible to use, but in a recent use it has come to the point that there may be multiple identical records in the resulting set, which we don't want.
As an example:
/** Forum Theme **/public class Theme {/** database ID **/private Integer id;/** title **/private String title;/** Topic content * */private String content;/** reply **/private set<reply> replies = new Hashset<reply> ();//getter.../ /setter ...}
/** Theme Reply **/public class Reply {/** database ID **/private Integer id;/** reply content **/private String content;/** reply to the topic **/private Theme theme;//getter...//setter ...}
For the sake of simplicity, only the example properties are listed, and the getter and setter methods are omitted. Now when we query Theme to grab the reply, then the HQL statement is: from Theme T left JOIN FETCH t.replies rs WHERE t.id=?, after executing the query, When you call the Uniqueresult () method you will get the correct result, but when you call the list () method, you will find that there are many duplicate records in the results list, exactly how many reply will have the theme. At this point you will certainly say that the call Uniqueresult () method is not finished? There is certainly no problem in this case where there is only one record, but sometimes we want to return a number of records. For example, when a fuzzy match is made according to the title property of Theme (regardless of the full-text index), then the HQL statement is: from Theme T-left JOIN FETCH t.replies rs WHERE t.title like? We're going to return an Li St List, you can only invoke the Query.list () method, which will inevitably cause multiple duplicate records. So how to solve it?
1. In addition to the DISTINCT keyword, hql becomes: from DISTINCT Theme T left JOIN FETCH t.replies rs WHERE t.title like?, which generally returns a definite result, but sometimes not. For example, in Oracle, when there is a field Clob,blob type, the line does not pass, because the data does not know whether the Clob,blob type of data is equal, the other database has not been tried, I guess not. So the DISTINCT keyword is not omnipotent.
2. In the return list containing the same record, manual removal of the same record, but this will add extra work, and you certainly do not want to do.
3. Call Query.setfirstindex (0) before calling the list () method. Setmaxresult (integer.max_value); Such a paging statement must have obtained all the records so that although the correct results can be obtained, However, you will find that the SQL statements that are not set up for paging are the same, which means that in this case, hibernate first obtains all eligible records before paging. There is no problem when you do not need to split the page, if you want to split the page and want to cascade crawl will get unnecessary records, because it is in memory paging. And so hibernate will also report a warning: Warning:firstresult/maxresults specified with collection fetch; Applying in memory! The general meaning is paging in memory, so there must be a performance problem, this question can be viewed: Click to open the link
In contrast, the individual feels that the 3rd solution is the most appropriate (if there is a better solution please advise), because as long as the page can not be paged to meet the requirements, if you want to be paged only do not cascade crawl, to get the entity association properties to write the query statement.
