[ 
https://issues.apache.org/jira/browse/SOLR-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573080#action_12573080
 ] 

Mike Klaas commented on SOLR-488:
---------------------------------

Perhaps I should have been more clear: it is very unlikely that there will be a 
bugfix release for 1.2, so the best that can be done is to look at the closed 
issues in JIRA for the highlighter to find the change that fixed the bug in the 
current version.

As for uniqueKey, it is about more than finding duplicates at document 
insertion time.  It is also a unique identifier for each document used for 
federated search, highlighting, and other places (exactly what you are looking 
for).  If you want to turn off Solr's duplicate detection, just add 
allowDups="true" to the <update/> you send to solr. 

> Solr does not generate highlights when uniqueId field is not defined in the 
> schema
> ----------------------------------------------------------------------------------
>
>                 Key: SOLR-488
>                 URL: https://issues.apache.org/jira/browse/SOLR-488
>             Project: Solr
>          Issue Type: Improvement
>          Components: highlighter
>    Affects Versions: 1.2
>         Environment: Windows Vista Business (x86, x64), latest Ubuntu server, 
> Apache Tomcat 6.0.14
>            Reporter: Tomer Gabel
>         Attachments: linkfield.HighlightingUtils.patch
>
>
> Solr does not generate highlights when there is no uniqueId field defined in 
> the schema. I believe the reason for this is that it's very difficult to 
> modify or extend the XmlWriter behavior, which is why highlights reside in 
> their own "section" in the response XML and subsequently need to be "linked" 
> to their respective documents via the uniqueId field.
> Our schema does not define a uniqueId for various reasons but we still need 
> highlights; the solution we came up with was to provide a user-definable 
> "link field," which is the document field whose value resides in the {{<lst 
> name="215">}} elements in the generated output. I will presently attach a 
> patch which adds a "hl.link" query parameter, which takes a field name and 
> uses that as the "link field." If the parameter is not specified the original 
> behavior is used, so backwards compatibility is maintained.
> As an aside, we've found this technique to be useful because our custom 
> handlers add a lot of information to each document, and the way the response 
> writer is implemented makes it nigh impossible to add information to any 
> specific document within the response. I should probably open an issue which 
> calls to reimplement this aspect of Solr.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to