I added the highlighting code I am using to this JIRA
(https://issues.apache.org/jira/browse/SOLR-1397). Afterwards I
noticed this JIRA (https://issues.apache.org/jira/browse/SOLR-1954)
which talks about another solution. I think David's patch would have
worked equally well for my problem, just would require later doing the
highlighting on the clients end. I'll have to give this a whirl over
the weekend.
On Fri, Jul 15, 2011 at 3:55 PM, Jamie Johnson <jej2...@gmail.com> wrote:
> Boy it's been a long time since I first wrote this, sorry for the delay....
>
> I think I have this working as I expect with a test implementation. I
> created the following interface
>
> public interface SolrExternalFieldProvider extends NamedListInitializedPlugin
> {
> public String[] getFieldContent(String key, SchemaField field,
> SolrQueryRequest request);
> }
>
> I then added to DefaultSolrHighlighter the following:
>
> in init()
>
> SolrExternalFieldProvider defaultProvider =
> solrCore.initPlugins(info.getChildren("externalFieldProvider") ,
> externalFieldProviders,SolrExternalFieldProvider.class,null);
> if(defaultProvider != null){
> externalFieldProviders.put("", defaultProvider);
> externalFieldProviders.put(null, defaultProvider);
> }
> then in doHighlightByHighlighter I added the following
>
> if(schemaField != null && !schemaField.stored()){
> SolrExternalFieldProvider externalFieldProvider =
> this.getExternalFieldProvider(fieldName, params);
> if(externalFieldProvider != null){
> SchemaField keyField = schema.getUniqueKeyField();
> String key = doc.getValues(keyField.getName())[0]; //I
> know this field exists and is not multivalued
> if(key != null && key.length() > 0){
> docTexts = externalFieldProvider.getFieldContent(key,
> schemaField, req);
> }
> } else {
> docTexts = new String[]{};
> }
> }
>
> else {
> docTexts = doc.getValues(fieldName);
> }
>
>
> This worked for me. I needed to include the req because there are
> some additional thing that I need to have from it, I figure this is
> probably something else folks will need as well. I tried to follow
> the pattern used for the other highlighter pieces in that you can have
> different externalFieldProviders for each field. I'm more than happy
> to share the actual classes with the community or add them to one of
> the JIRA issues mentioned below, I haven't done so yet because I don't
> know how to build patches.
>
> On Mon, Jun 20, 2011 at 11:47 PM, Michael Sokolov <soko...@ifactory.com>
> wrote:
>> I found https://issues.apache.org/jira/browse/SOLR-1397 but there is not
>> much going on there
>>
>> LUCENE-1522 <https://issues.apache.org/jira/browse/LUCENE-1522>has a lot of
>> fascinating discussion on this topic though
>>
>>
>>> There is a couple of long lived issues in jira for this (I'd like to try
>>> to search
>>> them, but I couldn't access jira now).
>>>
>>> For FVH, it is needed to be modified at Lucene level to use external data.
>>>
>>> koji
>>
>> Koji - is that really so? It appears to me that would could extend
>> BaseFragmentsBuilder and override
>>
>> createFragments(IndexReader reader, int docId,
>> String fieldName, FieldFragList fieldFragList, int maxNumFragments,
>> String[] preTags, String[] postTags, Encoder encoder )
>>
>> providing a version that retrieves text from some external source rather
>> than from Lucene fields.
>>
>> It sounds to me like a really useful modification in Lucene core would be to
>> retain match points that have already been computed during scoring so the
>> highlighter doesn't have to attempt to reinvent all that logic! This has
>> all been discussed at length in LUCENE-1522 already, but is there is any
>> recent activity?
>>
>> My hope is that since (at least in my test) search code seems to spend 80%
>> of its time highlighting, folks will take up this banner and do the plumbing
>> needed to improve it - should lead to huge speed-ups for searching! I'm
>> continuing to read, but not really capable of making a meaningful
>> contribution at this point.
>>
>> -Mike
>>
>
