-
-
Notifications
You must be signed in to change notification settings - Fork 670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a lenient mode to QueryParser #5
Comments
Not really a bug... but well. |
Requires #57 |
If you can give me some more specs I'd be willing to take a look at this. I like things that are about making it better for the user |
Improved the description. The ticket voluntarily does not give much implementation details. |
Tantivy's query parser can throw errors if the syntax of the query is invalid. There is a more lenient query parser[1] in the works but until then catch query parser errors and return an error response to the user. [1] quickwit-oss/tantivy#5
What's the status of this? I'm currently working on a web application, which exposes search functionality to non-technical users, and I was hoping I could let them try their hands into using advanced queries, with some sort of fallback in case they fail. This would be just what the doctor ordered. If #382 has merely stalled, and not dropped due to fundamental problems, I can put in the hours to get it over the finish line. |
Any news on this? It's problematic we still don't have a lenient mode when exposing the search feature to non-technical users... |
If someone wants to pick this feature it is up for grabs. |
Reassigning to @trinity-1686a |
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.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 text was updated successfully, but these errors were encountered: