PSeitz

I thought that the `docvalue_fields` option in `top_hits` reconstructs the object from those fields, but I just found out that's actually not the case and it just returns a flat...

Yes, I think we should change it. Currently we change the way paths are stored internally, depending on the `expand_dots` option. Internally we should have a canonical way to store...

We support the sql like `in` parameter `level: IN [info warn error]` You may also have a look at [quickwit](https://github.com/quickwit-oss/quickwit), which is built on tantivy for log search.

That use case and syntax seems rather niche, so I'm not sure we would want to add that in the query parser. maybe @fulmicoton has an opinion on this

So if I understand correctly, you would want a `PhraseQuery` that supports multiple terms. That's not supported currently and would probably make sense to add.

With the current API there are two issues. 1. To avoid eviction issues in the block cache, the docs need to be sorted, but this is not obvious to the...

You can use phrase search for this, it's not exact match though. You could use the raw tokenizer for exact match.

I think you need to phrase the query ```rust let raw_text_query = raw_query_parser.parse_query("\"Alick a01\"").unwrap(); ``` Ideally the query parser would handle this use case.

Are you referring to the `MoreLikeThisQuery`?

`a` is a term that gets indexed. The default behavior of the query is to OR connect all terms, which also contains `a`. Ignoring words like `a` is done via...