lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Klaas" <>
Subject Re: Support for custom Fragmenter when Highlighting
Date Tue, 18 Jul 2006 19:19:36 GMT
On 7/18/06, Andrew May <> wrote:
> I've been trying out the highlighting added to Solr recently (thanks - it's really
> useful), and I found myself wanting to highlight entire fields rather than just generating
> fragments. i.e. I want to use the Lucene NullFragmenter rather than the default GapFragmenter.

Cool, this was something I knew would be needed soon.  It makes sense
for fields like title, where the intent is purely highlighting and not

> In CommonParams, the variables added for highlighting were declared static (unlike the
> existing variables for the field list etc.). I made these non-static and everything still
> compiles. Is that OK?

They should be non-static

> In SolrPluginUtils I added "getHighlighter(Query query, SolrQueryRequest request,
> CommonParams params)". The idea was to move all the parameter checking into this method
> instead of having it in doStandardHighlighting(), and have this as the single place
> highlighters are generated.
> However, I didn't remove getDefaultHighlighter(Query query) because this is used by
> getHighlights(DocList docs, String[] fieldNames, Query query, SolrIndexSearcher searcher,
> int numFragments), which doesn't have access to the SolrQueryRequest or CommonParams.
> can't see anywhere this getHighlights method is used, but I didn't want to remove it.

It is safe to remove that--the main use to to perform highlighting
simply outside the confines of a request, but that can be accomplished
easily-enough with the other getHighlights method.

> In SolrPluginUtils I did an Eclipse "organise imports" (force of habit). This has
> re-arranged and shortened the list of imports considerably (there were some unused
> imports, and also I've got Eclipse configured to use * if there is more than 1 import
> a package).

Sounds like insofar as removing imports is concerned.  I'm not sure
what the Solr policy on asterisk imports is--I personally eschew them.

> So, should I submit the patch as is (via JIRA I assume?), or should I change it to make
> the minimal number of changes from the original classes?

I'd say get an initial reaction here then submit a patch.  It is
easier to work with a JIRA issue in place.

My main comment before seeing the patch is that the Fragmenter desired
might be different for different fields.  In my use, I'd want
GapFragmenter for the main text field and NullFragmenter for the title
field.  This complexity is why I didn't implement this in the first
patch.  If it is supported by your approach, that would be great.


View raw message