[
https://issues.apache.org/jira/browse/LUCENE-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keegan updated LUCENE-2272:
---------------------------------
Attachment: PNQ-patch.txt
There is a bug in PayloadNearQuery. If there are multiple top level spans that
match the query, only the payloads of the first one are retrieved. This patch
fixes this bug by iterating over all the top level spans to get the payloads
(see 'setFreqCurrentDoc')
> The base explain method can't be abstract. Something like
Ah, right. This is included in the patch
>The changes don't seem thread safe any more since there are now member
>variables. It may still be all right, but have you looked at this aspect?
I guess that could be said about PayloadTermSpanScorer and
PayloadNearSpanScorer, too (payloadScore, payloadsSeen). As for the
PayloadFunction classes, they seem lightweight enough to be created with each
query. Is there a better pattern?
Peter
> PayloadNearQuery has hardwired explanation for 'AveragePayloadFunction'
> -----------------------------------------------------------------------
>
> Key: LUCENE-2272
> URL: https://issues.apache.org/jira/browse/LUCENE-2272
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Reporter: Peter Keegan
> Assignee: Grant Ingersoll
> Attachments: payloadfunctin-patch.txt, PNQ-patch.txt
>
>
> The 'explain' method in PayloadNearSpanScorer assumes the
> AveragePayloadFunction was used. This patch adds the 'explain' method to the
> 'PayloadFunction' interface, where the Scorer can call it. Added unit tests
> for 'explain' and for {Min,Max}PayloadFunction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
