[
https://issues.apache.org/jira/browse/SOLR-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572407#action_12572407
]
Tomer Gabel commented on SOLR-488:
----------------------------------
Hi Mike,
We use a derivative of 1.2 here and have only just started looking at 1.3,
however because of our development schedule I doubt we'll be able to safely use
the trunk within the allotted time. Regardless, in 1.2 the highlights section
is either missing or empty (can't remember which); if the order is guaranteed
the same as the results this is probably good enough.
As for the query-time link field, it merely seemed like a path of least
resistance to getting the functionality I need while maintaining backwards
compatibility and with minimum intervention. I can't really think of a scenario
where this will change (for the same schema) between requests.
Finally, the unique key is insufficient because we simply don't use one. Due to
various performance and design goals we prefer to handle duplicates on our own
with an external system before even going 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.
