Skip to content
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

Closed
fulmicoton opened this issue Aug 16, 2016 · 8 comments · Fixed by #2129
Closed

Add a lenient mode to QueryParser #5

fulmicoton opened this issue Aug 16, 2016 · 8 comments · Fixed by #2129

Comments

@fulmicoton
Copy link
Collaborator

fulmicoton commented Aug 16, 2016

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.

@fulmicoton
Copy link
Collaborator Author

Not really a bug... but well.

@fulmicoton
Copy link
Collaborator Author

Requires #57

@fulmicoton fulmicoton self-assigned this Nov 9, 2016
@fulmicoton fulmicoton added this to the 0.7.0 milestone Jun 13, 2018
@drusellers
Copy link
Contributor

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

@fulmicoton
Copy link
Collaborator Author

Improved the description. The ticket voluntarily does not give much implementation details.

@fulmicoton fulmicoton assigned drusellers and unassigned fulmicoton Sep 16, 2018
@fulmicoton fulmicoton modified the milestones: 0.7.0, 0.8 Sep 16, 2018
@fulmicoton fulmicoton modified the milestones: 0.8, 0.9 Dec 26, 2018
poljar added a commit to matrix-org/pantalaimon that referenced this issue Jun 14, 2019
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
@slckl
Copy link
Contributor

slckl commented Feb 5, 2021

What's the status of this?
I see the opened PR has recently been closed, seemingly without result?

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.

@ClementNerma
Copy link

Any news on this? It's problematic we still don't have a lenient mode when exposing the search feature to non-technical users...

@fulmicoton
Copy link
Collaborator Author

If someone wants to pick this feature it is up for grabs.

@fulmicoton
Copy link
Collaborator Author

Reassigning to @trinity-1686a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Status: Done
5 participants