2014-08-29 19 views
0

2個SQL負載我有一個家長/孩子的關係是這樣的:Hibernate沒有爲父/子關係進行延遲加載。相反,它在查詢

@Entity 
@Table(name = "Agent", schema = "dbo", catalog = "MyTime") 
public class Agent implements Serializable { 
    private Set<AgentAttr> attributes = new HashSet<AgentAttr>(); 

    @OneToMany 
    @JoinColumn(name="Agent_GUID") 
    public Set<AgentAttr> getAttributes() { 
     return attributes; 
    } 

    public void setAttributes(Set<AgentAttr> attributes) { 
     this.attributes = attributes; 
    } 
} 

這DAO調用是對代理進行查詢。

Query query = getSession().createQuery("from Agent where userName = :userName"); 
query.setParameter("userName", userName); 
List list = query.list(); 

該查詢將返回代理對象,並在列表的每個元素中加載屬性集合。 當檢查Hibernate日誌時,它顯示它執行2個SQL查詢,一個加載代理,第二個加載屬性, 。

因爲Hibernate文檔說延遲加載是默認行爲,所以我沒有想到這一點。 我希望查詢返回的屬性爲空。然後Hibernate只在調用Agent.getAttributes()時加載它。 這就是延遲加載的重點,即只在需要時加載它,對嗎?我也試着明確地把@OneToMany(fetch = FetchType.LAZY)放在那裏,但是仍然一樣,不會執行延遲加載。

欣賞任何指示我可能做錯了什麼。謝謝。

下面是Hibernate的日誌:

2014/08/28 16:21:14.487 [DEBUG] <http-bio-8080-exec-3> (SqlStatementLogger.logStatement:109) - 
    /* 
from 
    Agent 
where 
    userName = :userName */ select 
     agent0_.Agent_GUID as Agent_GU1_1_, 
     agent0_.Address_Email as Address_2_1_, 
     agent0_.Address_SIP as Address_3_1_, 
     agent0_.Address_TEL as Address_4_1_, 
     agent0_.Address_XMPP as Address_5_1_, 
     agent0_.Company_GUID as Company_6_1_, 
     agent0_.Create_Tstamp as Create_T7_1_, 
     agent0_.Create_User as Create_U8_1_, 
     agent0_.Enabled as Enabled9_1_, 
     agent0_.First_Name as First_N10_1_, 
     agent0_.Last_Name as Last_Na11_1_, 
     agent0_.Location as Locatio12_1_, 
     agent0_.Password as Passwor13_1_, 
     agent0_.Role as Role14_1_, 
     agent0_.Security_Ans as Securit15_1_, 
     agent0_.Security_Q as Securit16_1_, 
     agent0_.Update_Tstamp as Update_17_1_, 
     agent0_.Update_User as Update_18_1_, 
     agent0_.User_Name as User_Na19_1_, 
     agent0_.Work_Status as Work_St20_1_ 
    from 
     MyTime.dbo.Agent agent0_ 
    where 
     agent0_.User_Name=? 
2014/08/28 16:21:14.487 [TRACE] <http-bio-8080-exec-3> (BasicBinder.bind:81) - binding parameter [1] as [VARCHAR] - [[email protected]] 
2014/08/28 16:21:14.794 [TRACE] <http-bio-8080-exec-3> (BasicExtractor.extract:78) - extracted value ([Agent_GU1_1_] : [VARCHAR]) - [9E5537A6-96FF-4656-9F75-70B58E44C0E9] 
2014/08/28 16:21:20.632 [DEBUG] <http-bio-8080-exec-3> (SqlStatementLogger.logStatement:109) - 
    /* 
from 
    AgentAttr 
where 
    agentGuid = :agentGuid */ select 
     agentattr0_.Agent_Attr_GUID as Agent_At1_4_, 
     agentattr0_.Agent_GUID as Agent_GU2_4_, 
     agentattr0_.Attr_Category as Attr_Cat3_4_, 
     agentattr0_.Attr_Name as Attr_Nam4_4_, 
     agentattr0_.Attr_Value as Attr_Val5_4_, 
     agentattr0_.Create_Tstamp as Create_T6_4_, 
     agentattr0_.Create_User as Create_U7_4_, 
     agentattr0_.Enabled as Enabled8_4_, 
     agentattr0_.Location as Location9_4_, 
     agentattr0_.Update_Tstamp as Update_10_4_, 
     agentattr0_.Update_User as Update_11_4_ 
    from 
     MyTime.dbo.Agent_Attr agentattr0_ 
    where 
     agentattr0_.Agent_GUID=? 
2014/08/28 16:21:20.632 [TRACE] <http-bio-8080-exec-3> (BasicBinder.bind:81) - binding parameter [1] as [VARCHAR] - [9E5537A6-96FF-4656-9F75-70B58E44C0E9] 
+0

您如何檢查AgentAttrs是否已加載? – WeMakeSoftware 2014-08-29 12:48:06

+0

我在查詢中設置了一個斷點並檢查返回列表中的每個Agent元素。我檢查屬性集合,並看到它加載了數據庫中的值。 – achanCSI 2014-08-29 13:06:49

+0

如果Collection是懶加載的,那麼Collection本身的類型應該是類似於ProxyCollection的類型。一旦你觸摸這個代理集合,它將用來自數據庫的「真實」對象初始化元素。這可能是你在調試器中觸摸集合,在集合中休眠。在獲取父對象之後您是否看到第二個SQL查詢? – WeMakeSoftware 2014-08-29 13:21:43

回答

0

根據規範中here

懶惰的策略是提示的持久性提供運行時數據應該被延遲加載它是首當訪問。允許執行熱切地獲取已爲其指定了LAZY策略提示的數據。

+0

但是,以下是它在Hibernate參考文檔中說的內容: 20.1.1。使用惰性關聯 默認情況下,Hibernate使用集合的懶惰選擇抓取和單值關聯的惰性代理抓取。這些默認值對大多數應用程序中的大多數關聯都有意義。 – achanCSI 2014-08-29 13:56:00

+0

這與規範不矛盾,對嗎?它仍然是延遲加載,並且對於一些複雜的對象,hibernate會延遲加載它們。 – WeMakeSoftware 2014-08-29 13:58:59

+0

好的,我想我說的是,如果Hibernate正在進行延遲加載,那麼我如何在查詢後查看所有兒童的值。我希望只有在調用Agent.getAttributes()時才能看到值。另外,Hibernate日誌顯示,它同時從數據庫加載父代和子代,並且兩個SQL語句一個接一個地執行。我想問題是我們如何知道延遲加載正在工作。 – achanCSI 2014-08-29 14:06:37