The role of the QueryParser is to give an off-the-shelf solution to people wanting to deliver a search box to end user.
Currently QueryParser::parse can return an error if the query does not match our query grammar.
e.g.: +(happy : the parenthesis is not closed.
This is great, but how should somebody writing a site handle this error?
Maybe for a log analysis search engine, displaying an explicit syntax error is a good idea, but for most use case, (ecommerce, document search, etc.) we want to never return an error and just do our best to handle the user query.
For this reason, we want to add a new parse_lenient that would never fail and always return a result.
pub fn parse_query_lenient(&self, query: &str) -> Box<Query> {
// ...
}The behavior of this lenient mode does NOT have to be very smart...
For instance, it could be a second very naive parser taking over when the initial parser failed.
For instance, this naive parser could remove all special characters and run the initial parser.
Smarter attempts to interpret the faulty user query are also welcome, as long as we return Box<Query> and we are confident the code will never panic.
The role of the
QueryParseris to give an off-the-shelf solution to people wanting to deliver a search box to end user.Currently
QueryParser::parsecan return an error if the query does not match our query grammar.e.g.:
+(happy: the parenthesis is not closed.This is great, but how should somebody writing a site handle this error?
Maybe for a log analysis search engine, displaying an explicit syntax error is a good idea, but for most use case, (ecommerce, document search, etc.) we want to never return an error and just do our best to handle the user query.
For this reason, we want to add a new
parse_lenientthat would never fail and always return a result.The behavior of this lenient mode does NOT have to be very smart...
For instance, it could be a second very naive parser taking over when the initial parser failed.
For instance, this naive parser could remove all special characters and run the initial parser.
Smarter attempts to interpret the faulty user query are also welcome, as long as we return
Box<Query>and we are confident the code will never panic.