Opened 15 years ago
Closed 15 years ago
#402 closed defect (fixed)
QueryParser should have option to combine same-prefix filters with OP_AND
Reported by: | Olly Betts | Owned by: | Olly Betts |
---|---|---|---|
Priority: | normal | Milestone: | 1.2.1 |
Component: | QueryParser | Version: | 1.0.16 |
Severity: | normal | Keywords: | |
Cc: | daniel.menard@… | Blocked By: | |
Blocking: | Operating System: | All |
Description
Thread: http://thread.gmane.org/gmane.comp.search.xapian.general/7720
Summary;
#157 changed QueryParser to combine boolean filters with the same prefix with OP_AND rather than OP_OR - the rationale being that for filters like "file type", type:pdf type:html would match no documents, so the sane interpretation is to pick either type.
However, this overlooks cases where a document can have multiple attributes of the same sort in some cases. The example in the thread is user tags - label:foo label:starred - and then it's generally more logical to use OP_AND.
This probably should be controllable on a per-prefix basis. In cases where each document can only have a single attribute from a set (like "hostname" or "mime type") then the current behaviour is great (and AND makes no sense as no document could match) but if each document can have multiple attributes from the set then it's likely that AND is a better default.
This could be specified in the API when the prefix is set, something like:
QueryParser::add_boolean_prefix(const std::string &field, const std::string &prefix, Xapian::Query::op op)
This should just be an API addition which can be made in an ABI compatible way, so marking for 1.2.x.
Change History (4)
comment:1 by , 15 years ago
Cc: | added |
---|
comment:2 by , 15 years ago
Milestone: | 1.2.x → 1.2.1 |
---|---|
Status: | new → assigned |
comment:3 by , 15 years ago
Milestone: | 1.2.1 → 1.0.21 |
---|
Fixed in trunk r14720.
Marking for backporting (slightly unsure if we should, but this affects a substantial number of people via notmuch and sup, and is a pretty safe change, despite the size of the patch).
comment:4 by , 15 years ago
Milestone: | 1.0.21 → 1.2.1 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
It seems we can't add API methods to 1.0.x now, or else the library versioning will clash with 1.2.x on some platforms. Linux looks to be OK, but I don't like the idea of diverging the API according to the platform, so I think it's best to just not make such changes now. Hence marking as fixed.
I have a patch which passes newly added testcases, but it's time I went to bed so I'll look it over tomorrow before committing.