[Xapian-devel] Bug and patch for +terms with wildcards

[Richard Boulton]

Olly Betts wrote:
> On Fri, Dec 08, 2006 at 06:44:56PM -0000, Richard Boulton wrote:
>>> I think a better approach would be to allow Xapian::Query() to be
>>> composed with other queries.  I know we used to allow this and it all
>>> got out of hand, but that was because we tried to make it compose in
>>> magic ways (e.g. Query() AND X would be X).  I'm just proposing that
>>> this works in the obvious was for an empty query, and you've already
>>> implemented this anyway!
>> I think the current behaviour of Xapian::Query() is good - it can't be
>> composed, it returns an error if you try and use it, but it is useful as a
>> placeholder when building up complex queries.  It's also not obvious to me
>> whether Xapian::Query() should match all documents or no documents
> 
> It definitely matches no documents - try it!  If you call:

Ah - my mistake.  It's even clearly documented as doing so.

So, it would be consistent and sensible to add the two static members to 
Xapian::Query you suggested.  However, in order to fix the query parser 
code as I did in my patch, I needed three special queries - match all, 
match nothing, and "uninitialised".  The reason for needing an 
"uninitialised" query is that when we have a list of items being 
composed with an operation, the query parser needs to be able to 
distinguish between a list which currently has no items in it 
(represented by an query constructed with no parameters, and for which 
.empty() returns true), and a list which has an item in it which matches 
nothing (represented by the MatchNothing query).

I suppose I could do the work in queryparser.lemony; either by defining 
a wrapper object in queryparser.lemony which can represent an 
"uninitialised" query as well as a standard one, or by making the 
queryparser.lemony use pointers instead of references to objects, and 
using NULL as the undefined query.  The former seems ugly, and the 
latter will need careful checking of the code to ensure that no NULL 
pointers get dereferenced.  Also, anyone else who writes a query parser 
is likely to come against the same issue, so I thought that having the 
Xapian::Query object able to represent each of the three special queries 
would be the neatest solution.

I'll try hacking up a patch in which I define a special object in 
queryparser.lemony which is able to represent a Xapian::Query, or an 
undefined query, and see how neat I can make that.

-- 
Richard