mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-14 07:42:28 +00:00
lancedb-gatefixer[bot]
b460989753
`MatchQuery(..., fuzziness=None)` raised a Pydantic validation error before a search could run because the field accepted only integers. Allow `Optional[int]`, retain the exact-match default of `0`, and make the documented parameter type explicit. The existing Rust binding already accepts and serializes the optional value. Regression coverage checks construction and JSON serialization for `None`, `0`, `1`, and `2`, plus native indexed searches with the default, explicit exact matching, automatic mode, and one- and two-edit controls. The two `None` regressions reproduced the original constructor error before the fix. Validation against the source-built extension in the locked uv environment: - `uv run --extra tests --extra dev maturin develop --extras tests,dev` - `uv run --no-sync --extra tests --extra dev pytest python/tests/test_fts.py -k 'match_query_fuzziness or fts_query_to_json' -q` — 10 passed. - `uv run --no-sync --extra tests --extra dev pytest python/tests/test_fts.py -q --disable-warnings` — 61 passed. - Locked-environment `ruff check .`, `ruff format .`, and `git diff --check` passed. The reported engine limitation remains observable with pinned Lance `14.0.0-beta.1`: its dataset planner compatibility gate rewrites `None` to zero, so a five-character AUTO query still omits one-edit matches. Automatic expansion for longer terms requires upstream Lance activation. The native acceptance regression uses a two-character term, whose documented automatic distance is zero, while the JSON regression verifies that Python forwards `None` as `null`. This keeps the repair within the issue's requested Python constructor scope. Fixes #4466 <!-- lance-gatekeeper-fix:v1 agent=f5f78166a4f0c7433e7890792b729c3d generation=1 --> Co-authored-by: Gatefixer <313497061+lancedb-gatefixer[bot]@users.noreply.github.com>