[Xapian-devel] GSoC xapian node binding thoughts

[Olly Betts]

On Mon, May 28, 2012 at 10:23:12PM -0700, Liam wrote:
> On Mon, May 28, 2012 at 2:44 PM, Olly Betts <olly at survex.com> wrote:
> > XOR can also take any number of subqueries.  And on trunk, OP_FILTER,
> > OP_AND_NOT, and OP_AND_MAYBE can also take any number of subqueries
> > (with OP(A, B, C) being interpreted as OP(OP(A, B), C)
> 
> XOR is missing from the online docs for Query(Query::op, Iterator,
> Iterator, termcount)

Thanks for pointing that out - it's been wrong for a while then (since
r3194, 2001-02-26):

    * Some modifications to XOR handling: should now behave like OR and 
      AND - doesn't need to be binary.  (*untested*) 

Now fixed on the 1.2 branch.  It was also missing that ELITE_SET can
take any number of subqueries in that comment, though it clearly says
it can elsewhere, and ELITE_SET would be rather useless if it only took
2 subqueries...

> We can include support for the other ops you mention and leave it commented
> out for now.

I would strongly recommend developing against trunk at this point
anyway.  You don't want to be wrapping anything which has been
deprecated in the C++ API, and it would be good to have wrappers done
for new features.  Once you have trunk wrapped, tweaking the wrappers to
work against 1.2 should be a simple matter of disabling a few parts.

> > Also, it would be nice to support a mixture of strings and query objects
> > as the subqueries (like we do in most of the dynamically typed languages).
> 
> You can include a term query in the list by writing {tname:'string'}, but
> certainly we could let 'string' be a shorthand for that.

It's largely syntactic sugar, but even syntactic sugar is still sweet.

Cheers,
    Olly