2013-08-21 41 views
1

我正在查看以下示例代碼以包含參考文檔並避免往返。Raven如何知道要包含哪些集合?

var order = session.Query<Order>() 
    .Customize(x => x.Include<Order>(o=>o.CustomerId)) // Load also the costumer 
    .First(); 
var customer = session.Load<Customer>(order.CustomerId); 

我的問題是如何烏鴉知道這意味着o=>o.CustomerId文件Customer /收集?查詢中提供的實體Customer從未在任何時間得到Order實體。然而,烏鴉聲稱,第二個查詢得到Customer可以完成對緩存,沒有任何網絡旅行。

如果是通過命名約定,這似乎是一個非常差/脆弱/脆弱的約定,當我需要包含多個文檔時會發生什麼?

例如,一輛汽車是以2個名字購買的,所以我想要鏈接回2個客戶,主要和次要客戶/司機。它們都存儲在Customer集合中。

var sale = session.Query<Sale>() 
    .Customize(x => x.Include<Sale>(o=>o.PrimaryCustomerId).Include<Sale>(o=>o.SecondaryCustomerId)) // Load also the costumer 
    .First(); 
var primaryCustomer = session.Load<Customer>(order.PrimaryCustomerId); 
var secondaryCustomer = session.Load<Customer>(order.SecondaryCustomerId); 

如何在1次網絡旅程中完成上述操作? Raven如何知道這個o=>o.PrimaryCustomerIdo=>o.SecondaryCustomerId是對同一張表Customer的引用,因爲顯然屬性名稱和集合名稱不對齊?

回答

2

Raven沒有「表格」的概念。它確實知道「收藏」,但它們只是一種便利機制。在幕後,所有文檔都存儲在一個大型數據庫中。唯一使「收集」的是每個文檔都有一個Raven-Entity-Name元數據值。

您顯示的兩個示例都會導致一次往返(每次)。你的代碼對我來說看起來很好。

我的問題是Raven如何知道這個o=>o.CustomerId暗示客戶文檔/集合?在查詢中提供的實體Customer沒有任何時間獲得Order實體。

它不需要在查詢中提供。只要存儲在Sale文檔的CustomerId字段中的數據是完整文檔密鑰,那麼該文檔將被返回到客戶端並加載到會話中。

然而,Raven聲稱,第二個獲取客戶的查詢可以針對緩存完成,無需任何網絡旅程。

這是正確的。會話容器會跟蹤返回的所有文檔 - 不僅僅是查詢結果中的文檔。因此,稍後當您使用相同的文檔密鑰調用session.Load時,它已在會話中擁有它,因此它不需要返回到服務器。

無論您是查詢,加載還是包含 - 文檔都不會反序列化爲靜態類型,除非您將其拉出會話。這就是您在session.Load<Customer>調用中指定Customer類型的原因。

如果是通過命名約定,這似乎是一個非常差/脆弱/脆弱的慣例採用...

不,它由存儲在其中的是一個文件密鑰如"customers/123"該屬性的值。每個文檔都可以通過其文檔鍵進行尋址,無論是否知道該類的靜態類型。

當我需要包含多個文檔時會發生什麼?

完全一樣的東西。對於可以包含或加載到會話中的文檔數量沒有限制。但是,您應該確保在using聲明中打開該會話,以便正確處置它。會話是「工作單元容器」。

將如何烏鴉,甚至知道這個o=>o.PrimaryCustomerIdo=>o.SecondaryCustomerId是因爲明顯的屬性名稱和集合名稱不用排隊了一個相同的表客戶參考?

同樣,這些字段的名稱並不重要。重要的是這些字段中的數據包含文檔ID,例如"customers/123"。如果你沒有存儲完整的字符串標識符,那麼你將需要在lambda表達式中構建文檔鍵。換句話說,如果Sale.CustomerId僅包含數字123,那麼您需要將其與.Include<Sale>(o=> "customers/" + o.CustomerId)一起包含。

+0

馬特,這是如何與Guid ID一起工作的?你顯示的例子是帶順序ID的字符串。 Guid沒有實體名稱,那麼Raven如何解析正確的集合進行查詢?或者它會根據Guid查詢所有內容? – Alwyn

+1

如果您爲'Id'使用字符串,則可以完全控制文檔密鑰。如果使用整數或Guid,則使用「FindFullDocumentKeyFromNonStringIdentifier」約定爲您創建字符串文檔關鍵字,默認情況下該關鍵字預先指定了該類型的複數形式和斜槓。你可以閱讀更多關於非字符串標識符[這裏](http://ravendb.net/docs/2.5/client-api/basic-operations/loading-editing-existing-document#non-string-identifier)。 –

+1

換句話說,「文檔鍵」與「Id」相關*,但不一定完全相同。你不會有一個只有「123」的文檔鍵。它必須是「客戶/ 123」。對於指導也是一樣。 –

相關問題