在網(wǎng)上查找資料,說(shuō)在為了延遲加載<one-to-one>,<many-to-one>所關(guān)聯(lián)的對(duì)象,需要設(shè)置被關(guān)聯(lián)的對(duì)象<class name="" lazy="true">,我也這樣做了,但是仍然沒(méi)有效果.
仔 細(xì)閱讀了Hibernate的手冊(cè),才發(fā)現(xiàn)原來(lái)要延遲加載<one-to-one>,<many-to-one>所關(guān)聯(lián)的對(duì)象 時(shí),除了要指定lazy="true"外,還需要運(yùn)行期字節(jié)碼增強(qiáng),而我省去了這一步,所以延遲加載沒(méi)有效果.同時(shí)還發(fā)現(xiàn)在默認(rèn)情況下,<one- to-one>,<many-to-one>的lazy屬性是"proxy"而不是"true"!因此如果直接采用lazy的默認(rèn)值, 是可以延遲加載的.
總結(jié)一下:
<many-to-one>默認(rèn)的屬性是lazy="proxy",此時(shí)默認(rèn)是會(huì)延遲加載的.在指定了lazy="true"之后,必須要經(jīng)過(guò)運(yùn)行期字節(jié)碼增加,延遲加載才有效果.
而<one- to-one>相對(duì)要復(fù)雜一點(diǎn),延遲加載還要受到constrained屬性的限制.constrained="false"時(shí)表明實(shí)體和被關(guān)聯(lián)到 的實(shí)體的約束不是強(qiáng)制的,即存在一個(gè)實(shí)體時(shí),它通過(guò)<one-to-one>關(guān)聯(lián)的實(shí)體可能存在,也可能不存在,這時(shí)在查詢實(shí)體 時(shí),Hibernate總會(huì)發(fā)起一次查詢檢查<one-to-one>所關(guān)聯(lián)的實(shí)體是否存在,而這時(shí)已經(jīng)可以把one-to-one關(guān)聯(lián)的實(shí) 體查詢出來(lái)了,因此在<one-to-one>關(guān)系中,如果constrained="false",總是會(huì)立即加載關(guān)聯(lián)到的實(shí)體.
如果當(dāng)constrained="true",且lazy="proxy"(默認(rèn)),是可以延遲加載的.
如果當(dāng)constrained="true",且lazy="true"時(shí),需要經(jīng)過(guò)運(yùn)行期字節(jié)碼增加,延遲加載才會(huì)奏效.
但是這里我還是有個(gè)疑問(wèn),既然在lazy="proxy"時(shí),已經(jīng)實(shí)現(xiàn)了延遲加載的效果,為什么在lazy="true"時(shí),還需要?jiǎng)討B(tài)字節(jié)碼增強(qiáng)才能實(shí)現(xiàn)延遲加載呢?
Re: Hibernate中的延遲加載
以后在one-to-one或many-to-one中不會(huì)再有l(wèi)azy="true"了,你可以理解成no-proxy.
[1]起碼還是好的方向: 默認(rèn)就可以lazy了. 而且來(lái)了extra :)
[2]寫Hibernate的哥們也是要活命的嘛, 不改變?cè)趺磥?lái)的咨詢費(fèi), 不過(guò)Hibernate的migration寫的也還不錯(cuò).
[3]constrained如你所說(shuō), 而且我估計(jì)這個(gè)屬性以后不會(huì)有太大變更.
1)如果需要代理的類實(shí)現(xiàn)了一個(gè)接口,那么這些框架就在運(yùn)行時(shí)使用reflect反射機(jī)制來(lái)創(chuàng)建一個(gè)實(shí)現(xiàn)了此接口的類作為代理類。
2)如果這個(gè)類沒(méi)有實(shí)現(xiàn)任何接口,那么就會(huì)使用cglib庫(kù)提供的方法來(lái)動(dòng)態(tài)創(chuàng)建一個(gè)此類的子類作為代理類。其實(shí)也是使用了反射機(jī)制。cglib就是處理第二種情況的一個(gè)通用框架。
方法是:在主控方的<one-to-one>上加constrained=true,在被控方的class上加lazy=true,其實(shí)這個(gè)方法是可以的
我們都知道,一對(duì)一有兩種實(shí)現(xiàn)方式,主鍵關(guān)聯(lián)和外鍵關(guān)聯(lián)
主鍵關(guān)聯(lián):就是說(shuō)兩個(gè)表的主鍵是一樣的
product(id,name) image(id,name)
其中image的id引用product的id,product是主,image是次
外鍵關(guān)聯(lián):就是說(shuō)是通過(guò)一個(gè)字段引用另一個(gè)表的主鍵
product(id,name) image(id,name,productid)
其中image的productid引用product的id,product是主,image是次
在主鍵關(guān)聯(lián)時(shí),按如下進(jìn)行實(shí)體映射,是可以實(shí)現(xiàn)延遲加載的


































當(dāng)使用外鍵關(guān)聯(lián)是,如果按如下方式編寫映射文件,使不能進(jìn)行延遲加載的


































為什么呢,我認(rèn)為是在主方product中,有這樣一句話property-ref="product"
這句話的意思是說(shuō)加外鍵關(guān)聯(lián)類的屬性,如果不指定這個(gè)屬性,關(guān)聯(lián)類的主鍵就會(huì)被使用
也就是說(shuō),如果不制定這個(gè),在查找image時(shí)就會(huì)使用
select * from image where imageid==product_id 而不是
select * from image where productid==product_id
我們?cè)谥纏roduct_id的時(shí)候,需要找image中productid等于product_id記錄,而不是用image的主鍵作為比較
去掉propery-def后,倒是可以延遲加載,但在讀取product.getImage()方法時(shí)會(huì)報(bào)沒(méi)有指定id記錄的異常,不過(guò)這也正常,我們?cè)趺茨苡胕mage的主鍵和product_id建立查詢條件呢
至于為什么這樣,我不是很清楚
總之:我目前的結(jié)論是:用主鍵關(guān)聯(lián),可以延遲加載,用外鍵關(guān)聯(lián),暫時(shí)不考慮延遲加載
至于為什么,希望能到大家的幫助