How do you build and combine where filters in the Weaviate v4 Python client?

## Filters are objects, not dictionaries The defining change in the v4 Python client is that a filter is a typed object built with a fluent API rather than a nested dict. That matters practically: your editor completes the operator names, a typo fails at construction time instead of producing a query that silently matches nothing, and filters are ordinary Python values you can build, name, store and pass around. ```python from weaviate.classes.query import Filter articles = client.collections.get("Article") response = articles.query.near_text( query="climate policy", limit=10, filters=Filter.by_property("category").equal("news"), ) ``` ## The comparison vocabulary From `Filter.by_property("prop")` you reach: - `equal(value)` and `not_equal(value)` — exact match on text, numbers, booleans, dates. - `greater_than`, `greater_or_equal`, `less_than`, `less_or_equal` — ranges over numbers and dates. - `like(pattern)` — wildcard text matching, where `*` covers any run of characters and `?` a single one. Useful for prefix matching; expensive if you lead with a wildcard. - `contains_any([...])` and `contains_all([...])` — for array-valued properties, asking whether the array intersects your list or covers it entirely. `contains_any` is also the idiomatic way to express "category is one of these". - `is_none(True)` — matches objects where the property was never set, which is distinct from matching an empty string. Beyond properties there are metadata entry points: `Filter.by_id()` for the object UUID, and `Filter.by_creation_time()` / `Filter.by_update_time()` for timestamp ranges, which give you "only documents ingested since yesterday" without storing a timestamp property of your own. ## Composition Two equivalent styles exist and both appear in real code. Operator style reads well for fixed conditions: ```python f = ( Filter.by_property("category").equal("news") & Filter.by_property("word_count").greater_than(500) & ~Filter.by_property("status").equal("draft") ) ``` The usual Python pitfall applies: `&` and `|` are the operators, not the `and` / `or` keywords. Writing `f1 and f2` does not build a conjunction — Python evaluates truthiness and hands you one of the two objects, so the query runs with half the constraint and no error anywhere. Also remember `&` binds tighter than comparison operators, so parenthesise generously. List style suits filters assembled dynamically: ```python conditions = [Filter.by_property("category").equal(c) for c in chosen] f = Filter.any_of(conditions) ``` `Filter.all_of` and `Filter.any_of` take a list and are the natural fit when the number of conditions depends on user input. Building a list and folding it is cleaner than accumulating with `&` in a loop, and it makes the empty case explicit — an empty condition list should mean "no filter", so pass `None` rather than an empty combinator. ## Where filters can be attached The same object is accepted by every read path: - `query.near_text(..., filters=f)` and its `near_vector` / `near_object` siblings — constrained vector search. - `query.fetch_objects(filters=f, limit=100)` — a purely structured query with no vector involved. This is the right call for "show me every draft article", and reaching for a vector search with a dummy query vector instead is a common beginner mistake. - Aggregation and deletion paths accept filters too, so a bulk delete reuses exactly the condition you validated with a read. That last pattern is worth internalising as a safety habit: before a bulk delete, run the identical filter through `fetch_objects` and inspect what comes back. ## Schema is a prerequisite Filters are evaluated against Weaviate's inverted index, not by scanning objects. Properties therefore have to be indexed for filtering in the collection definition. Property-level indexing is a schema-time decision, and it is the reason a filter can fail or behave unexpectedly on a property that looks perfectly ordinary in the returned objects. Data types matter too: filtering a numeric-looking value that was declared as text with `greater_than` is a type mismatch, not a lexicographic comparison. ## Cross-reference filters When a collection has cross-references, `Filter.by_ref(link_on="hasAuthor").by_property("name").equal("Ada")` filters on a linked object's property. This is powerful and genuinely relational-feeling, but it costs an extra traversal per candidate; heavy use on a hot query path is a design smell that usually means the value should be denormalised onto the object being searched.