[ http://issues.apache.org/jira/browse/SOLR-24?page=comments#action_12419367 ]
Hoss Man commented on SOLR-24: ------------------------------ Bill: I beleive what you are seeing is an issue with the Highlighter not playing nice with Analyzers that produce multiple tokens in the same position -- Mike mentioend this in the email discussion, but i assumed it was reagarding using TermPosition information ... in the example app "name" is a stored field, so i'm not sure why the indexing Analyzer would affect highlighting (perhaps it's yet anohter aspect of the highlighter package i don't understand) Incidently, We might as well capture here a summary of the dicussion from last week... http://www.nabble.com/-jira--Created%3A-%28SOLR-24%29-Add-Highlighting-to-standard-request-handler-tf1834206.html 1) patch generally look good 2) I'm hesitent to change SolrPluginUtils.getParam() In this particular case (using the "highlight" param to indicate both that highlighting should be turned on, and to override the default highlighting fields) I think a better API would be two seperate params, and the more i think about it the more i like that solution in general -- much as Mike pointed out that "Significant whitespace scares me" in response to truely ridiculous suggestion i made, significant *empty* space scares me ... so i would vote for changing that and then commiting. Incidently, i got a response from Erik H giving this patch his thumbs up a few days ago, but looking at the thread now i realize it came staight to me and not the list. > Add Highlighting to standard request handler > -------------------------------------------- > > Key: SOLR-24 > URL: http://issues.apache.org/jira/browse/SOLR-24 > Project: Solr > Type: New Feature > Components: search > Reporter: Mike Klaas > Attachments: highlight_patch_v1.diff > > This patch adds highlighting functionality to solr request handlers it also > refactors StandardRequestHandler to use the common functionality provided in > SolrPluginUtils. I'd have preferred to do two separate patches, but creating > two mutually-dependent patches on a repo without being able to commit a > revision was daunting. > ----------------------------------- > Refactoring StandardRequestHandler: > 1. Moved solr.util.CommonParams to its own class. Removed DisMax-specific > parameters, and placed in a subclass. > 2. StandardRequestHandler uses CommonParams to store config-time parameter > values (new feature) > 3. StandardRequestHandler uses SolrPluginUtils methods for duplicate > functionality > 4. Some of said SPU methods have grown a "params" parameter to enable them to > use default values. (Note: instead of passing this around, something like a > RequestHelper class which carries the SolrRequest and Param values would be > useful. This class could house the utility methods that require Request > parameters). > 5. SolrPluginUtils.getParam() only uses the default parameter if it is null, > not blank. > -------------------------------------- > Highlighting: > 1. Highlighting is controlled by three request parameters: > highlight: list of fields to highlight, or highlight the default field if > at all present > maxSnippets: maximum number of snippets to return for each field > highlightFormatterClass: 'solr.<classname>' or full package path of > highlight.Formatter subclass to use in highlighting. > 2. Default formatter is to use <em> tags. There are issues with this > approach, but are mitigated with the ability to specify a custom Formatter. > Definately should consider alternatives (a custom xml approach to denote > highlit regions will require some Highlighter package hackery). > 3. Document summaries are returned as a separate element under <response> > format is still up for discussion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
