Opened 17 years ago

Last modified 12 months ago

#159 new enhancement

Should be possible to introspect on Query objects

Reported by: Richard Boulton Owned by: Not currently assigned
Priority: normal Milestone: 2.0.0
Component: Library API Version: git master
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Operating System: All

Description (last modified by 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.

Attachments (1)

query_introspect.patch (1.1 KB ) - added by Richard Boulton 17 years ago.
Sketch of some of the API required for this

Download all attachments as: .zip

Change History (8)

comment:1 by Richard Boulton, 17 years ago

Operating System: All
Owner: changed from Olly Betts to Not currently assigned

(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.
  1. 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.
Last edited 10 years ago by Olly Betts (previous) (diff)

by Richard Boulton, 17 years ago

Attachment: query_introspect.patch added

Sketch of some of the API required for this

comment:3 by Richard Boulton, 16 years ago

Description: modified (diff)
Type: defectenhancement

comment:4 by Olly Betts, 10 years ago

Milestone: 1.3.x

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).

Last edited 7 years ago by Olly Betts (previous) (diff)

comment:5 by Olly Betts, 10 years ago

Milestone: 1.3.x1.3.3

comment:6 by Olly Betts, 9 years ago

Milestone: 1.3.31.3.4

comment:7 by Olly Betts, 8 years ago

Milestone: 1.3.41.4.x

Time to be brutal - this ought not block 1.4.0.

comment:8 by Olly Betts, 12 months ago

Milestone: 1.4.x2.0.0
Version: SVN trunkgit master

[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.

Note: See TracTickets for help on using tickets.