[ https://issues.apache.org/jira/browse/SOLR-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572312#action_12572312 ]
Mike Klaas commented on SOLR-488: --------------------------------- Thanks for the patch! Tomer, I just tested this scenario under trunk (1.3dev), and Solr _does_ highlight documents if no uniqueKey is specified. It is true that the highlight data is not labeled, but it is guaranteed to appear in the same order as the documents in the <results> section, so they are identifiable. Why do you propose a query-time "link" field? Do you need to be able to vary the field from request to request? Also, it would be helpful to know why uniqueKey is not sufficient for this purpose. > 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.