qdrant: Filters don't function properly when only the key attribute is specified
Current Behavior
When you only specify a filter key but not a match or a range, the filter will always return an empty set.
It seems like the filter tries to match against null
which would explain the result for specified payloads.
Expected Behavior
I would expect empty rules to be ignored if not specified, so that the filter ambiguously returns every point that contains the key.
Steps to Reproduce
openapi/tests/openapi_integration/helpers/collection_setup.py:
{
"id": 1,
"vector": [0.05, 0.61, 0.76, 0.74],
"payload": {"city": "Berlin", "population": 4500000}
},
openapi/tests/openapi_integration/test_filter.py:
def test_match_key():
response = request_with_validation(
api='/collections/{collection_name}/points/search',
method="POST",
path_params={'collection_name': collection_name},
body={
"vector": [0.2, 0.1, 0.9, 0.7],
"limit": 3,
"filter": {
"must": [
{
"key": "population",
}
]
}
}
)
assert response.ok
print(response.json())
json = response.json()
assert len(json['result']) == 1
ids = [x['id'] for x in json['result']]
assert 1 in ids
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 17 (10 by maintainers)
@varshneydevansh @amit-62
I started typing a longer explanation to guide you through a possible implementation when I realized that I basically done it myself.
I decided to push my solution instead to streamline this issue has we had many back and forth already.
Hopefully there will be issues which are more amenable to new contributors 👍
https://github.com/qdrant/qdrant/pull/2745
No need to touch. the web UI 😃
Look for the type
FieldCondition
and try to use our validation infrastructure to return a client side error if only the key attribute is specified.@varshneydevansh Sure go for it, I am not aware of anyone working on this.
@russcam Thanks for the vote 👍
I vote for this being an illegal state. The semantics of a filter on
null
and empty values are covered byis_null
andis_empty
, respectively.It is difficult to attribute semantic to a filter which is missing the action part.
IMHO it is either an illegal state or a pass through like in my draft PR.
Given the confusion it generates, I believe making it an illegal state by returning an explicit error to the user would be the most sensible way forward.
I think I would rather expect this query to be invalid at all