1. 程式人生 > >重新學習 Hibernate fetch lazy cascade inverse 關鍵字(轉)

重新學習 Hibernate fetch lazy cascade inverse 關鍵字(轉)

Hibernate最讓人頭大的就是對集合的載入形式。
書看了N次了,還是沒有真正理解Hibernate。所以下午專門做了下測試,對配置檔案的意思加深了認識。

假設有兩個表,Photos(一) --- picture(多)Photo包含picture集合

結論1: HQL程式碼 > fetch(配置) > lazy (配置)
結論2: 預設 lazy="true"
結論3: fetch 和 lazy 主要是用來級聯查詢的, 而 cascade 和 inverse 主要是用來級聯插入和修改的
結論4: 如果你是用spring來幫你管理你的session, 並且是自動提交,延遲載入就等於沒載入~_~(當然
除非你手動重新開啟session然後手動Hibernate.initialize(set);然後關閉session.
結論5: cascade主要是簡化了在程式碼中的級聯更新和刪除。
j結論6:老爸可以有多個孩子,一個孩子不能有多個老爸,而且老爸說的算, 孩子圍著老爸轉。
所以Photos老爸要有權力所以 cascade 這個關鍵子都是送給老爸的, 也就是級聯更新,
老爸改姓了,兒子也得跟著改,呵呵。“不然,就沒有零花錢咯”。
而Picture兒子整體捱罵,但是還是要維護父子之間良好的關係,對老爸百依百順,所
以老爸就說,兒子,“關係,由你來維護(inverse="true") ,不然就不給零花錢。呵。”。
<set name="pictures" inverse="true" cascade="all">
<key>
<column name="photosid" not-null="true" />
</key>
<one-to-many class="girl.domain.Picture" />
</set>

測試程式碼:

Photos p = ps.getById(1);
Set<Picture> set = p.getPictures();
for(Picture pic : set){
System.out.println(pic.getId());
}

配置檔案的一部分:
<set name="pictures" inverse="true" cascade="all" >
<key>
<column name="photosid" not-null="true" />
</key>
<one-to-many class="girl.domain.Picture" />
</set>

測試過程會對配置檔案不斷修改:並且從來不曾手動重新開啟session

測試結構:

當配置條件為 lazy=true 一句查詢 測試程式碼中沒有呼叫getPicture() 正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?

lazy=true 一句查詢 有getPicture()
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?


lazy=true 一句查詢 有getPicture() 並且訪問了裡面的元數Picture 且有異常丟擲
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?


lazy="false" 兩句查詢 肯定沒問題,因為全部資料都個查了出來 所以怎麼呼叫都正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?
Hibernate: select pictures0_.photosid as photosid1_, pictures0_.id as id1_, pictures0_.id as id2_0_, pictures0_.photosid as photosid2_0_, pictures0_.name as name2_0_, pictures0_.clicked as clicked2_0_, pictures0_.uploaddate as uploaddate2_0_, pictures0_.size as size2_0_, pictures0_.description as descript7_2_0_, pictures0_.uri as uri2_0_ from super.picture pictures0_ where pictures0_.photosid=?


fetch="join" 一句查詢 效果 == lazy="false" 呵呵,哪個效率高,我就不知道了。。。。。。。。。。。
Hibernate: select photos0_.id as id0_1_, photos0_.userid as userid0_1_, photos0_.typeid as typeid0_1_, photos0_.name as name0_1_, photos0_.createtime as createtime0_1_, photos0_.description as descript6_0_1_, photos0_.faceid as faceid0_1_, photos0_.uri as uri0_1_, pictures1_.photosid as photosid3_, pictures1_.id as id3_, pictures1_.id as id2_0_, pictures1_.photosid as photosid2_0_, pictures1_.name as name2_0_, pictures1_.clicked as clicked2_0_, pictures1_.uploaddate as uploaddate2_0_, pictures1_.size as size2_0_, pictures1_.description as descript7_2_0_, pictures1_.uri as uri2_0_ from super.photos photos0_ left outer join super.picture pictures1_ on photos0_.id=pictures1_.photosid where photos0_.id=?

不加fetch="join" 一句查詢 沒有getPicture() 正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?

不加fetch="join" 一句查詢 有getPicture() 正常
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?

不加fetch="join" 一句查詢 有getPicture() 並且訪問裡面的元素Picture的ID 有異常丟擲
Hibernate: select photos0_.id as id0_0_, photos0_.userid as userid0_0_, photos0_.typeid as typeid0_0_, photos0_.name as name0_0_, photos0_.createtime as createtime0_0_, photos0_.description as descript6_0_0_, photos0_.faceid as faceid0_0_, photos0_.uri as uri0_0_ from super.photos photos0_ where photos0_.id=?

來個兩兵交戰 fetch="join" lazy="true" 呵呵 結果,一句查詢, 結構正常 所以就當lazy不存在好了。 看來fetch 是老大。、、、、、、、、、、、、、
Hibernate: select photos0_.id as id0_1_, photos0_.userid as userid0_1_, photos0_.typeid as typeid0_1_, photos0_.name as name0_1_, photos0_.createtime as createtime0_1_, photos0_.description as descript6_0_1_, photos0_.faceid as faceid0_1_, photos0_.uri as uri0_1_, pictures1_.photosid as photosid3_, pictures1_.id as id3_, pictures1_.id as id2_0_, pictures1_.photosid as photosid2_0_, pictures1_.name as name2_0_, pictures1_.clicked as clicked2_0_, pictures1_.uploaddate as uploaddate2_0_, pictures1_.size as size2_0_, pictures1_.description as descript7_2_0_, pictures1_.uri as uri2_0_ from super.photos photos0_ left outer join super.picture pictures1_ on photos0_.id=pictures1_.photosid where photos0_.id=?


可以參閱:http://www.iteye.com/topic/2633