While the query interface has already been dropped for binary stores, there is still some legitimate (limited) use-case of it for object-stores (think database backends).
On the other hand, the naive filtering currently done by the serializes that just loads all data into memory and performs all checks in Python provides no practical benefit to anybody. Library users could just write a couple of similar (and more optimized!) lines of code themselves or look into optimizing their datastructures for their particular use-case instead.
The plan therefor is to make implementation of this interface optional for object stores as well and drop all code related to naive filtering. The remaining code will remain as an abstraction for structured datastores that can actually do something sensible with the queries they are given.
While the query interface has already been dropped for binary stores, there is still some legitimate (limited) use-case of it for object-stores (think database backends).
On the other hand, the naive filtering currently done by the serializes that just loads all data into memory and performs all checks in Python provides no practical benefit to anybody. Library users could just write a couple of similar (and more optimized!) lines of code themselves or look into optimizing their datastructures for their particular use-case instead.
The plan therefor is to make implementation of this interface optional for object stores as well and drop all code related to naive filtering. The remaining code will remain as an abstraction for structured datastores that can actually do something sensible with the queries they are given.