2012-05-30 118 views
2

無法從Solr集合中刪除文件中的密鑰。無法刪除Solr密鑰

更新Solr的收集與此:

<cfoutput query="fileQuery"> 
    <cfset theFile = defaultpath & "#fileID#.pdf" /> 

    <cfif fileExists(theFile)> 
    <cfindex 
     action="update" 
     collection="file_vault_solr" 
     type="file" 
     key="#theFile#" 
     title="#documentName#" 
     body="fileNumber,documentName" 
     custom1="/filevault/#filealias#" 
     custom2="#fileNumber#" 
     custom3="#documentName#" 
    > 
    </cfif> 
</cfoutput> 

但是,試圖刪除目錄中的鑰匙時,它根本不起作用。以下是用於(嘗試)刪除密鑰的代碼:

<cfoutput query="deletedFile"> 
    <cfset theFile = defaultpath & "#fileID#.pdf" /> 

    <!--- Remove the deleted file from the collection. ---> 
    <cfindex 
    collection="file_vault_solr" 
    type="file" 
    action="Delete" 
    key="#theFile#" 
    > 
</cfoutput> 

但是,密鑰不會被刪除。唯一有效的工作是清除整個目錄並重新索引所有文件。

任何見解?

+0

你有沒有發現過?我目前有同樣的問題。 – Tomalak

+0

@Tomalak:不,從未找到解決方案。現在我不再在那裏工作了,所以如果我願意,我不能回去確認。 – ale

+2

無賴。這個問題讓我很緊張。 Adobe似乎沒有人再測試這些東西。 – Tomalak

回答

2

關鍵必須與Solr的索引完全匹配。因此,請確保兩者中的「defaultpath」相同,並檢查大小寫是否相符,因爲我相信Solr區分大小寫。

1

要調試這個,我建議你添加status =「myStatusVar」給cfindex調用。然後在添加和刪除上看看發生了什麼。如果刪除沒有返回已刪除的計數。然後有一個密鑰不匹配。

<cfindex 
collection="file_vault_solr" 
type="file" 
action="Delete" 
key="#theFile#" 
status="myStatusVar" 
> 
7

經過大量的調試,我發現了。

這種行爲的原因是一個非常......呃......不幸的呃......「設計決定」Adobe在實現ColdFusion和Solr之間的接口時所採取的。

因此,你有索引文件的Solr集合,並希望有選擇地清除磁盤上不再存在的索引文件。我敢肯定這是你一直在確切的情況

假設:

  • 有一個名爲/path/to/file您的系統上
  • 它Solr的集合foo的索引。

當你發出一個<cfindex collection="foo" action="delete" key="/path/to/file">,ColdFusion的發送以下HTTP請求到Solr:

POST /solr/foo/update?wt=xml&version=2.2 (application/xml; charset=UTF-8) 
<delete><id>1247603285</id></delete> 

這是Solr的將愉快地履行一個完全合理的要求。唯一奇怪的是<id>中的數字。無論如何,該操作完成後,文件將從索引中消失。

重新索引文件並將其從磁盤中刪除。現在:

  • 也不再是一個名爲/path/to/file您的系統上的文件,但
  • 仍然 Solr的集合foo的索引。

讓我們再次做同樣的<cfindex action="delete">操作。

POST /solr/foo/update?wt=xml&version=2.2 (application/xml; charset=UTF-8) 
<delete><id>/path/to/file</id></delete> 

咦?ID中不應該有數字嗎?

事實證明,有人Adobe公司認爲這將是使用號碼的索引文件的唯一ID,來,唔,節省空間一個歡樂的聰明的想法,我想。

但是由於某些不可解釋的原因,這隻有當問題文件仍然存在時纔會發生。如果它不再存在,ColdFusion將會注意並傳遞路徑。

檢查數字表明它適合32位有符號整數值。 (我檢查過,集合中的uid字段有很多負值。)

因此,這看起來好像他們使用某種哈希算法返回32位並在int中查找。 CRC32浮出水面,但事實並非如此。另外,java.util.zip.CRC32返回long,所以首先不會有任何負值。

Java中另一種可用的32位散列是... java.lang.Object.hashCode()

賓果。

"/path/to/file".hashCode() // -> 1247603285 

因此,解決辦法是永遠不會刪除其路徑的文件,但總是這樣:

<cfindex collection="foo" action="delete" key="#path.hashCode()#"> 

對於已不存在這樣做正確的事的文件。

更重要的是:對於仍然存在的文件,這也是正確的--ChartFusion會發送哈希代碼。

在Adobe解決這個問題之前,這是一個安全和簡單的解決方法。

請注意,文件路徑區分大小寫,並且必須與存儲在索引中的路徑完全匹配。

快速

<cfsearch collection="foo" name="foo"> 

沒有任何criteria將返回所有索引條目,所以檢索孤立條目它不是一個大問題的確切路徑。


Eric Lippert explains object hash codes and why it is a bad idea to use them for anything "practical" in an application這是一篇.NET文章,但也適用於Java。

歸結爲:Adobe應該將實際的路徑存儲在Solr集合中,並保留它們似乎嘗試過的Solr的性能優化。


我已經針對Adobe的ColdFusion bug數據庫提交了Bug 3589991

+2

感謝您的大力支持。這篇文章可能也是你感興趣的:http://blogs.msdn。com/b/ericlippert/archive/2005/10/24/482447.aspx –

+0

@Eric「當你這樣做會傷害」標籤讓我發笑。 – Tomalak