Should be possible to introspect on Query objects

[Richard Boulton]

In particular, it should be possible to determine the operator performed by the "top-level" query in the query object, get a list of the subqueries, get any appropriate parameters supplied (eg, valno and end of range for a VALUE_RANGE query, window size for a phrase query, etc) and get the term, wqf and position for a leaf query.

This API will necessarily involve quite a few methods - we need to make sure that it is no more complicated than really necessary, and be sure that it doesn't expose internals of the query representation (preventing us modifying these in future).

One particular issue is that we can't easily just return the "operator" used in the query, because leaf queries use a special "magic" value for the operator parameter. There are several solutions to this: 1) make OP_LEAF public. 2) make "get_operator()" return -1, and just document that it does that, 3) add an "is_leaf()" method, and document that get_operator() shouldn't be called unless "is_leaf()" returns false.

[Richard Boulton]

(reassigning to nobody, since I don't think Olly's likely to be working hard on this right now, and nor am I.)

I forgot to mention two reasons for wanting this support:

1. Somebody asked recently on the mailing list for a way to display a human-displayable explanation of a query (ie, user-visible). This could be put together with the information available from this introspection interface.

2. Fixing bug #157 requires keeping track of the valuenumber for value range queries. Being able to get this out of the query would be the best approach: since the queryparser is internal, it can get the valuenumber directly from the internals, but it seems wrong for the queryparser to depend on internal hooks; it's reasonable that other people might want to write query parsers, so there shouldn't be anything special that our query parser does that other query parsers couldn't do.

[Richard Boulton]

Sketch of some of the API required for this

[Olly Betts]

f4f38b0cde256a6881a2086cbe83ee11260ce33a adds the start of an introspection interface - with what's there you can walk the query tree and get the type of each node.

Query::get_terms_begin() allows you to read the term for a node which is a term - not sure if an additional method to get the termname directly is worthwhile or not.

I've not yet added methods to allow introspection of all the details of all query types, and I've not yet added any test coverage (though it does at least work in informal testing).

[Olly Betts]

Time to be brutal - this ought not block 1.4.0.

[Olly Betts]

[4fb286495452f96c077fc31d85aaed95f1ab9ce5] allows introspecting on wqf and pos for terms in a query.

More could be done, though - as the original report says "eg, valno and end of range for a VALUE_RANGE query, window size for a phrase query, etc".

This isn't a release blocker though.