If you are going to compare scores across multiple indices, I'd suggest
considering one of the patches here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=31841

Chuck

  > -----Original Message-----
  > From: Erik Hatcher [mailto:[EMAIL PROTECTED]
  > Sent: Monday, November 22, 2004 6:30 AM
  > To: Lucene Users List
  > Subject: Re: Question about multi-searching [re-post]
  > 
  > 
  > On Nov 22, 2004, at 9:18 AM, Cocula Remi wrote:
  > >> (First of all : what is the plurial of index in english ; indexes
or
  > >> indices ?)
  > 
  > We used "indexes" in Lucene in Action.  Its a bit ambiguous in
English,
  > but indexes sounds less formal and is acceptable.
  > 
  > >> For that, I parse a new query using QueryParser or
  > >> MultiFieldQueryParser.
  > >> Then I search my indexes using the MultiSearcher class.
  > >>
  > >> Ok, but the problem comes when different analyzer are used for
each
  > >> index.
  > >> QueryParser requires an analyzer to parse the query but a query
  > >> parsed with an analyzer is not suitable for searching into an
index
  > >> that uses another analyzer.
  > >>
  > >> Does anyone know a trick to cope this problem.
  > 
  > Nothing built into Lucene solves this problem specifically.  You'll
  > have to come up with your own MultiSearcher-like facility that can
  > apply different queries to different indexes and merge the results
back
  > together.  This will be awkward when it comes to scoring though,
since
  > each index is using a different query.
  > 
  > >> Eventually I could run a different query on each index to obtain
  > >> several Hits objects.
  > >> Then I could write some collector that collects Hits in the order
of
  > >> highest scores.
  > >> I wonder if this could work and if it would be as efficient as
the
  > >> MultiSearcher . In this situation does it make sense to compare
the
  > >> scores of two differents Hits.
  > 
  > No, it won't make good sense to compare the scores between the
queries,
  > but I suspect our queries are pretty close to one another if all
that
  > varies is the analyzer.  It still will be an awkward comparison
though,
  > but maybe good enough for your needs?
  > 
  >     Erik
  > 
  > 
  >
---------------------------------------------------------------------
  > To unsubscribe, e-mail: [EMAIL PROTECTED]
  > For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to