<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    posts - 165, comments - 198, trackbacks - 0, articles - 1
      BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理
    一篇非常好的 Hibernate? 文章
    出自: http://guxing.blog.enorth.com.cn/article/174717.shtml

    Tags: fetch
    Hibernate最讓人頭大的就是對集合的加載形式。

    書看了N次了,還是沒有真正理解Hibernate。所以下午專門做了下測試,對配置文件的意思加深了認識。

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

    結(jié)論1: HQL代碼 > fetch(配置) > lazy (配置)
    結(jié)論2: 默認 lazy="true"
    結(jié)論3: fetch 和 lazy 主要是用來級聯(lián)查詢的,?? 而 cascade 和 inverse 主要是用來級聯(lián)插入和修改的
    結(jié)論4: 如果你是用spring來幫你管理你的session, 并且是自動提交,延遲加載就等于沒加載~_~(當(dāng)然除非你手動重新打開session然后手動Hibernate.initialize(set);然后關(guān)閉session.
    結(jié)論5:? cascade主要是簡化了在代碼中的級聯(lián)更新和刪除。
    j結(jié)論6:老爸可以有多個孩子,一個孩子不能有多個老爸,而且老爸說的算, 孩子圍著老爸轉(zhuǎn)。所以Photos老爸要有權(quán)力所以 cascade?這個關(guān)鍵子都是送給老爸的,?也就是級聯(lián)更新,老爸改姓了,兒子也得跟著改,呵呵。“不然,就沒有零花錢咯”。而Picture兒子整體挨罵,但是還是要維護父子之間良好的關(guān)系,對老爸百依百順,所以老爸就說,兒子,“關(guān)系,由你來維護(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

    測試結(jié)構(gòu):

    當(dāng)配置條件為 lazy=true一句查詢 測試代碼中沒有調(diào)用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 一句查詢 有g(shù)etPicture()
    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
    一句查詢? 有g(shù)etPicture() 并且訪問了里面的元數(shù)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" 兩句查詢? 肯定沒問題,因為全部數(shù)據(jù)都個查了出來 所以怎么調(diào)用都正常
    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"一句查詢? 沒有g(shù)etPicture() 正常
    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" 一句查詢? 有g(shù)etPicture() 正常
    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"一句查詢 有g(shù)etPicture() 并且訪問里面的元素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=?

    來個兩兵交戰(zhàn) fetch="join" lazy="true"? 呵呵 結(jié)果,一句查詢, 結(jié)構(gòu)正常 所以就當(dāng)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=?



    主站蜘蛛池模板: 国产黄片不卡免费| 青青草97国产精品免费观看| 日本免费电影一区二区| 亚洲免费日韩无码系列| 国产亚洲福利精品一区二区| 精品国产免费一区二区| 亚洲av永久中文无码精品综合| 啦啦啦中文在线观看电视剧免费版| 国产精品亚洲午夜一区二区三区| 中文字幕无码不卡免费视频| 四虎亚洲精品高清在线观看| 夜夜嘿视频免费看| 噜噜综合亚洲AV中文无码| 国产免费爽爽视频免费可以看| 无忧传媒视频免费观看入口| 亚洲五月综合缴情在线观看| 最好免费观看高清在线| 久久亚洲AV成人无码电影| 无码国产精品一区二区免费式直播 | 久久久久亚洲AV无码专区桃色| 免费观看四虎精品成人| 亚洲开心婷婷中文字幕| 99热精品在线免费观看| 国产精品亚洲片在线va| 亚洲午夜爱爱香蕉片| 久久99青青精品免费观看| 亚洲第一香蕉视频| 韩国欧洲一级毛片免费| 中文字幕无线码中文字幕免费 | 亚洲sss综合天堂久久久| 好爽好紧好大的免费视频国产| 国产免费久久久久久无码| 午夜亚洲www湿好大| 久久久久久久91精品免费观看| 亚洲αⅴ无码乱码在线观看性色| 亚洲精品成人在线| 91免费在线播放| 一级毛片人与动免费观看| 亚洲最大在线观看| 免费一级特黄特色大片在线观看| 国产一区二区三区免费|