Implement the query parsing in the default doc mapper & disable range queries

[fulmicoton]

Range queries are not possible today in quickwit. We need to disable them.

[fmassot]

Renamed the issue as we first need to implement the query parsing in the default doc mapper.

[fulmicoton]

@evanxg852000 I see that you assigned the ticket to yourself. Here is a bit of guidance.

One "clean" way to do this is as follows.

Depend on the tantivy-query-grammar crate.
https://docs.rs/tantivy-query-grammar/0.15.0/tantivy_query_grammar/enum.UserInputAst.html

Parse the user query into an UserInputQuery object.
Go recursively through the Ast (no worries there cannot be any cycle) and check that there are no range within the query.

If there are no range, just go on with parsing the query the way we did before. (it feels stupid because we end up parsing the query twice but that's fine).

If there is a range, return an Error explaining ranges are not supported for the moment.

[fulmicoton]

@evanxg852000 I think you should also factorize our trivial query building logic.

A good way to do it might be to introduce a pub(crate) in doc_mapper.rs

pub(crate) fn build_query(
    schema: &Schema,
    request: &SearchRequest,
    default_fields: Vec<String>,
) -> Result<Box<dyn Query>, QueryParserError> { ... }

That implements does the field name resolution, the no range query check, and the query parsing boilerplate.

Then have the different mapper call this function.

(an alternative solution that might seem logic would be to have a blanket implementation in DocMapper and add a default_fields method in the trait.. I am not fond of this solution because it requires adding the default_fields method in the trait, but feel free to challenge it.)

[evanxg852000]

Thanks @fulmicoton for the explanation, I was already wondering how would I plug my code to check for Range since the tantivy query parser does all the work without exposing intermediate step/object. But yes this is the cleanest solution for our case while avoiding duplication of the parser.
On the second note, I will go with your solution. To me, this has an advantage in handling all this in one site.

[fulmicoton]

The benefit is minor... By adding the build_query function, you can implement the logic in every call traits. On the other hand, it forces us to add a default_fields method in the trait, even though this is not necessarily something that always makes sense.