[
https://issues.apache.org/jira/browse/LUCENE-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-903:
----------------------------
Attachment: lucene-903.patch
in general i'm not fond of the inspecting the string to determine whether the
math is correct ... in an ideal world every query would have it's own unit test
class and it would have a "testExplanation" method that would know exactly what
structure (ie: how many sub-details) to expect from an artificially constructed
query instance. the current approach of having big "explanation" test classes
that validate an explanation by comparing them to the scores is a fairly big
hack (and i say that as the guy that added it).
But i'm okay with the string comparisons as a "Convenience" to make it easier
for us to test the explanations of the core queries (since so many of them
follow very clear patterns) ... but i think we should avoid having any sort of
expectation on the string for custom queries (either that they match "product
of" or that they match "other:")
my main concern is purely with giving people a way to do the same kind of
Explanation testing they could do before (that the root value equals the score)
even if the details of their explanation don't fit any of the patterns of the
existing core queries. (i'd hate for people to not even do shallow testing of
their Explanations just because we don't give them a method for doing so)
this refactoring...
- makes verifyExplanations a public method in CheckHits that anyone can call
- adds a "deep" boolean option to verifyExplanations
- adds variants of CheckHits.checkExplanations and the ExplanationAsserter to
make the "deep" testing optional
- makes QueryUtils.checkExplanations use the "deep" option
- makes TestExplanations explicitly use deep testing
...at the moment, the "old" APIs default to deep==false but i'm on board with
changing those to "true" if you want to (in theory it's a non-backawards
compatible API change, but since it's in src/test we can probably get away with
it).
> FilteredQuery explanation inaccuracy with boost
> -----------------------------------------------
>
> Key: LUCENE-903
> URL: https://issues.apache.org/jira/browse/LUCENE-903
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 2.2
> Reporter: Doron Cohen
> Assignee: Doron Cohen
> Priority: Minor
> Fix For: 2.2
>
> Attachments: lucene-903.patch, lucene-903.patch
>
>
> The value of explanation is different than the product of its part if boost >
> 1.
> This is exposed after tightening the explanation check (part of LUCENE-446).
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
