DisjunctionMaxQuery with tie breaker=1 same as MultiFieldQueryParser?

: If I want to search let's say "ipod" in three different fields (device,
: sound,technology)
: Would be the same to use a DisjunctionMaxQuery with the tie braker = 1 than
: to use a MultiFieldQueryParser with and OR to build the boolean queries?

strictly speaking even with tie breaker of 1, a DisjuctionMaxQuery differs
from a BooleanQuery in the details of how the score is calculated when a
document matches *some* of the subclasses, but not all .. there is no
"coord" concept in DisjunctionMaxQuery.

If you look at the explain output of various queries agaisnt various docs
you'll see what i mean.


-Hoss


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

Thanks Hoss for the useful info.

Acording the coord(q,d) definition it's calculated at document level. It's
said:
is a score factor based on how many of the query terms are found in the
specified document
If I am just searching for a term, "ipod" in this case, how would be coord
computed? Would in this case coord(q,d) matter at all? (I understand that
not)

In case I search for 2 terms in 2 fields but making compulsory for both
terms to appear in at least one of the fields, would coord matter? (I
understand that not)

As far as I understant documentation, coord just matters when you are not
doing a pure AND between the query terms you want to search.

Am I correct?



hossman wrote:

I am reading lucene in action 2,there is some question about it.

When a flush occurs, the writer creates new segment and deletion files in
the Directory. However,
these files are neither visible nor usable to a newly opened IndexReader
until the writer commits the
changes. It's important to understand this difference. Flushing is done to
free up memory consumed by
buffered changes to the index, whereas committing is done to make all
flushed changes persistent and
visible in the index.

Why Flushing does not make all flushed changes persistent even if it had
created new segment?
Flushing does not mean flush any change to disk?


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

Flushing means stuff (added docs, deletions) buffered in RAM are moved
to disk, ie, written as new segment files.

But the new segments_N file, referencing these new segments, is not written.

Nor are the files "sync"'d.

This means a newly opened or reopened reader will not see the changes.

In order to make the changes "visible" you have to call IndexWriter.commit.

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

: If I am just searching for a term, "ipod" in this case, how would be coord
: computed? Would in this case coord(q,d) matter at all? (I understand that
: not)

in theory your SImilarity coord() function would be called to find out
what hte coord value for "1 of 1" should be ... but in reallity TermScorer
doesn't look at coord, just BooleanQuery (and maybe some of the
SpanQueries, i can't remember)

: In case I search for 2 terms in 2 fields but making compulsory for both
: terms to appear in at least one of the fields, would coord matter? (I
: understand that not)

you lost me, it really depends on what exactly the query structure is --
the short answer: if there is a BooleanQuery involved, then coord matters.

: As far as I understant documentation, coord just matters when you are not
: doing a pure AND between the query terms you want to search.
:
: Am I correct?

if all clauses are mandatory, then all docs that match should have
identical values for the coord, so you are correct, it shouldn't matter.


-Hoss


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