Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Thu, 15 Jun 2006 15:27:08 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: Lucene Dev <java-dev@lucene.apache.org>
Subject: Seeking feedback on LUCENE-557
Message-ID: <Pine.LNX.4.58.0606151505100.11094@hal.rescomp.berkeley.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Regarding "search vs explain - score discrepancies"...

   http://issues.apache.org/jira/browse/LUCENE-557

...I got sidetracked by a pesky anoyance called "work" for a little while,
but I'm looking at this again, and I'd like to commit some varient of the
patches I added to that bug -- the notable exception being to remove the
tests that fail because of LUCENE-451 (which I hope to tackle next) and
attach them to that issue -- but before I commit anything, I was wondering
if folks could give me a little feedback on two issues I'm not 100%
confident of...


1) Modifying existing search tests to implicitly check explain

LUCENE-557-modify-existing-tests.patch modifies (almost) every core test I
could find that used an IndexSearcher to use a modified IndexSearcher that
implicitly tests explanations as well.  I mainly wrote this to help me
spot the problem queries when writing new test classes, but I'm wondering
what people think about commiting this change.

It essentially boils down to this...

   -  Searcher searcher = new IndexSearcher(directory);
   +  Searcher searcher = new CheckHits.ExplanationAssertingSearcher(directory);

...across 43 Test classes.  Should those changes be committed?  Part of me
says "no" because it's kind of ugly, but another part of me says "yes"
because it's the best way to ensure that as fuctionality evolves, future
committers will be alerted if they cahnge the search behavior of query
without making corrisponding hanges to the explain behavior.

2) SpanScorer.explain HACK fix

NearSpans.skipTo is broken (see LUCENE-569).  This apparently doesn't
affect too many people (or if it does, they haven't been filing bugs about
it)  but it does make SpanScorer.explain lie.  I don't understand
SpanQueries enough to feel comfortable fixing LUCENE-569 (even though
paul.elschot has pointed out an alternate version of NearSpans that
doesn't have this bug) but I do have a HACK patch for SpanScorer.explain
that works arround the bug by just looping over NearSpans.next instead of
using NearSpans.skipTo.

Should This HACK be commited, or is it better to leave explanations for
SpanNear queries broken untill someone has the confidence to fix LUCENE-569?


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org