[Xapian-tickets] [Xapian] #224: Supply and optimise more OP_VALUE_ comparison operators

[Xapian]

#224: Supply and optimise more OP_VALUE_ comparison operators
-----------------------------+-------------------------------
 Reporter:  Richard Boulton  |             Owner:  visvesh
     Type:  enhancement      |            Status:  new
 Priority:  low              |         Milestone:  1.4.x
Component:  Matcher          |           Version:  git master
 Severity:  minor            |        Resolution:
 Keywords:  GoodFirstBug     |        Blocked By:
 Blocking:                   |  Operating System:  All
-----------------------------+-------------------------------
Changes (by Olly Betts):

 * owner:  Olly Betts => visvesh

Comment:

 > Why is the module labeled as "Matcher" instead of "Query"?

 The "Component" field in trac is really just one tool trac provides to try
 to impose a bit of order on the ticket pile, so I wouldn't read too much
 into what it's set to.  It's often the case that a ticket doesn't actually
 fit completely into a single component.  Free-form tagging via the
 "Keywords" field would allow multiple areas of the code to be specified,
 but you then get issues like someone using "matching" instead of "matcher"
 - with "Component" there's a pre-defined list of values to choose from.
 (One can also set a different default owner for a new ticket based on the
 component the submitter specifies, but currently we don't make use of
 that.)

 The part you've chosen to look at does involve adding new operators to
 Query objects, but you'll also need to modify files under `matcher/` to
 actually implement it.

 We don't actually have a "Query" component in trac.  "Library API" would
 cover that part, but I think overall the things discussed in this ticket
 are more about the matcher part than the API part.

 > Also I am unable to figure out the data type of data member internal in
 query object. Does its data type depend on the constructor called?

 The internal member is a (reference-counted) pointer to a
 `Xapian::Query::Internal` object, but that's an abstract base class and
 it's concrete type will be a subclass of that, depending on the query
 operator/leaf subquery type (e.g. `QueryTerm` for a term, `QueryAnd` for
 `OP_AND`).
-- 
Ticket URL: <https://trac.xapian.org/ticket/224#comment:11>
Xapian <https://xapian.org/>
Xapian