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
>
