Opened 17 years ago
Closed 15 years ago
#254 closed defect (fixed)
Setting QueryParser default_op to OP_NEAR doesn't set an explicit window size
Reported by: | Kevin Duraj | Owned by: | Olly Betts |
---|---|---|---|
Priority: | normal | Milestone: | 1.1.2 |
Component: | QueryParser | Version: | 1.0.7 |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Operating System: | All |
Description
When searching with more then 2 parameters on Boolean operator NEAR it throws and error: Exception: Can't use NEAR/PHRASE with a subexpression containing NEAR or PHRASE
Test case: http://myhealthcare.com/cgi-bin/search?q=american+actor+kevin&bool=near
-Kevin Duraj
Change History (9)
comment:1 by , 17 years ago
Component: | Other → QueryParser |
---|
comment:2 by , 17 years ago
Operating System: | Linux → All |
---|---|
Owner: | changed from | to
comment:3 by , 17 years ago
Yes, this is the exact code used.
$qp = Search::Xapian::QueryParser->new(); $qp->set_default_op(OP_NEAR); $enq = $db->enquire($qp->parse_query($terms));
comment:4 by , 16 years ago
Keywords: | NEAR removed |
---|---|
Milestone: | 1.0.7 → 1.0.8 |
Status: | new → assigned |
Summary: | Boolean operator NEAR does not accept more than 2 params → Setting QueryParser default_op to OP_NEAR doesn't set an explicit window size |
Version: | 1.0.6 → 1.0.7 |
This will work in 1.0.7 for multiple terms as well as it does for just two terms in 1.0.6.
But that's not actually very well - the window size for the OP_NEAR isn't set explicitly, so the default of the number of terms is used. I think it would make more sense to default_op of OP_NEAR to work much like an explicit a NEAR b NEAR c. So I'm going to keep this bug open for this remaining issue, but retitle appropriately.
comment:6 by , 16 years ago
Milestone: | 1.1.0 → 1.1.1 |
---|
Not an ABI breaking change, so bumping to 1.1.1.
comment:9 by , 15 years ago
Milestone: | 1.1.7 → 1.1.2 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Version: | 1.0.2 → 1.0.7 |
Oops, changed version not milestone, and failed to mark as fixed...
A test case on a website isn't much use. I can't fire it up in the debugger to find out why something happens, nor use it to verify that a fix works.
Am I right in thinking this arises when using code something like: