What about a common class with chooseable aggregation method?

Will commit tomorrow or Saturday, as it is a pretty minor variant of the BoostingTermQuery

Was actually just thinking we could have a simple Function Interface:

public interface PayloadFunction{
   float currentScore(currentScore, currentPayloadScore);

   float finalScore(numPayloadsSeen, payloadScore);
}

and it could be passed into the constructor. Then, in processPayload, you could just have

          payloadScore = function.score(payloadScore, similarity.scorePayload(term.field(), payload, 0, positions.getPayloadLength()));

instead of

          payloadScore = Math.max(payloadScore, similarity.scorePayload(term.field(), payload, 0, positions.getPayloadLength()));

or whatever is there.

Then, the getPayloadScore() method (see my patch) would be:

return (payloadsSeen > 0 ? (function.finalScore(payloadsSeen, payloadScore)) : 1);

What did you have in mind? I'm pretty tired, so the above may be a bit whacked.

Yeah, thats basically what I was thinking - then you could do min score or whatever as well - .

Does it really needs all of those args though? I guess you could possibly do more that way, but it almost seems you just need:

public interface PayloadAggregationFunction{
   void aggregate(score);
   float score();
}

Refactors BoostingTermQuery to be a BoostingFunctionQuery. Adds in several PayloadFunction implementations. All tests pass

Will commit today or tomorrow.

Next take on this:

1. Added includeSpanScore flag, which allows you to ignore the score from the TermQuery part of the score and only count the payload.

2. Deprecated Similarity.scorePayload(String fieldName, ...) to a similar method that also takes in the Doc id. Now, in theory, you could have different scoring for payloads based on different documents, fields, etc. The old method just calls the new one and passes in a NO_DOC_ID_PROVIDED value (-1).

3. Added a Marker Interface named PayloadQuery and marked the various PayloadQueries. This could be useful for Queries that work with other PayloadQueries (more exclusive than the fact that they are SpanQueries.

I really do intend to commit this

Is this done?

Should we deprecate BoostingTermQuery, with this?

Deprecated BoostingTermQuery and committed

Going to reopen and see about passing along the position information into both the new scorePayload() method and into the PayloadFunction, as it may be useful to know this information when scoring payloads.

Pass in position information as well for scoring. Will commit tomorrow.

Committed revision 804178.

Committed the position patch

BoostingFunctionTermQuery implements equals but not hashcode - important for a query class I think.

remove some unused imports
added missing license header

Added hashCode to BoostingFunctionTermQuery

Added hashCode/equals to PayloadFunction classes

added hashcode/equals to query - really it should be handling the equals/hashcode for boost, not subclasses (which will be likely to forget it - you should check super classes for these things anyway as well).

BoostingFunctionTermQuery is a subclass of SpanTermQuery, but both of them use a weak equals method (using instanceof)
so while BoostingFunctionTermQuery.equals(SpanTermQuery) should equal SpanTermQuery.equals(BoostFunctionTermQuery), it doesn't.

Added new hashCode/equals for both classes that work properly.

Added a couple tests for these fixes

reopen to fix hashCode/equals

Looks good, Mark. +1 for you to commit. Good catch.

thanks for the review,

r804994