[Xapian-tickets] [Xapian] #663: Make ValueRangeProcessor return a Query object

Xapian nobody at xapian.org
Thu Apr 28 00:44:00 BST 2016


#663: Make ValueRangeProcessor return a Query object
-------------------------+------------------------------
 Reporter:  olly         |             Owner:  olly
     Type:  enhancement  |            Status:  assigned
 Priority:  normal       |         Milestone:  1.3.6
Component:  QueryParser  |           Version:  SVN trunk
 Severity:  normal       |        Resolution:
 Keywords:               |        Blocked By:
 Blocking:               |  Operating System:  All
-------------------------+------------------------------
Changes (by olly):

 * milestone:  1.3.x => 1.3.6


Comment:

 I have been working on this.

 I've tried making `operator()` return `std::pair<Xapian::Query,
 std::string>` but it makes writing a custom range processor class feel
 rather clumsy.  A few details:

  * The second parameter is a "grouping key" - I used `str(slot)` for value
 ranges
  * I used `std::make_pair(Xapian::Query(), std::string())` to mean "range
 not handled"
  * I provided a helper method `make_value_range(Xapian::valueno slot,
 const std::string& begin, const std::string& end)` to create a value range
 (with `slot == Xapian::BAD_VALUENO` meaning "range not handled", and
 `end.empty()` meaning `OP_VALUE_GE`), which helps a bit
  * `FieldProcessor` really ought to be consistent with this - we could
 change its API incompatibly at this point, but I am aware people have
 already started to use it

 I'm wondering if the `OP_FILTER_KEY` approach would work better overall -
 the key benefits I can see are:

  * Simple return type (`Xapian::Query`)
  * Simple cases (prefixed terms, value ranges) can just work automatically
 by introspecting the returned `Query` object
  * Complex cases (e.g. wanting to group `date:` range processor and
 `date:` field processor together, and grouping a range which may be
 optimised using terms) are supported
  * Something like `OP_NULL` can cleanly signify "range not handled" -
 having a "no query" `Query` object (distinct from a `Query` which matches
 nothing) seems like it would be more widely useful

--
Ticket URL: <https://trac.xapian.org/ticket/663#comment:7>
Xapian <//xapian.org/>
Xapian



More information about the Xapian-tickets mailing list