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

Support lenient parser in bindings #109

Closed
GodTamIt opened this issue Aug 14, 2023 · 2 comments · Fixed by #114
Closed

Support lenient parser in bindings #109

GodTamIt opened this issue Aug 14, 2023 · 2 comments · Fixed by #114
Labels
enhancement New feature or request

Comments

@GodTamIt
Copy link
Contributor

Now that quickwit-oss/tantivy#2129 has landed, it'd be nice to start thinking about lenient parsing support in the bindings. Obviously, a new version of the crate has to be released but starting to think about this.

I've started working on this, but there are a few points I'd like to iron out how we'd expose the QueryParserError enum. It'd be nice to have types for the errors, but QueryParserError is currently a Rust enum.

An (strawman) idea I had was to have separate classes for each error type. Then, optionally, organize them in a submodule underneath tantivy, i.e. tantivy.query_parser_error or something. Then, the interface could look something like this from the Python side:

@dataclass
class ParseQueryLenientResult:
    query: Query
    errors: List[Union[query_parser_error.SyntaxError, query_parser_error.UnsupportedQuery, ...]]

def parse_query_lenient(query: str, default_field_names: Optional[List[str]]) -> ParseQueryLenientResult:
    ...

cc @adamreichold @cjrh if y'all have thoughts

@adamreichold
Copy link
Collaborator

Then, the interface could look something like this from the Python side:

Concerning the Union type hint, wouldn't a type hierarchy involving inheritance be pretty idiomatic for Python, e.g. SyntaxError and UnsupportedQuery both inheriting from some QueryParserError base class?

@GodTamIt
Copy link
Contributor Author

Then, the interface could look something like this from the Python side:

Concerning the Union type hint, wouldn't a type hierarchy involving inheritance be pretty idiomatic for Python, e.g. SyntaxError and UnsupportedQuery both inheriting from some QueryParserError base class?

I posted #114 as a strawman for how this might look.

I played around with using a base class, but there are some challenges with using them with PyO3. I've commented specifically on the PR and in the code about this.

@cjrh cjrh added the enhancement New feature or request label Sep 13, 2023
@cjrh cjrh closed this as completed in #114 Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants