From 03b767a0ca67dd95edef939a170e020e1ab4fc17 Mon Sep 17 00:00:00 2001 From: Ivan Despot <66276597+g-despot@users.noreply.github.com> Date: Thu, 13 Aug 2026 16:33:49 +0200 Subject: [PATCH 1/4] chore: regenerate uv.lock for weaviate-client 4.23.0 pyproject.toml was bumped to 4.23.0 while that version was tagged but not yet published, so the lockfile could not be regenerated at the time and kept resolving 4.22.0. Every workflow that runs a bare uv sync failed at dependency install as a result. 4.23.0 is now on PyPI, so the lockfile resolves. --- uv.lock | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/uv.lock b/uv.lock index b0f0e87f5..876adf000 100644 --- a/uv.lock +++ b/uv.lock @@ -1840,7 +1840,7 @@ wheels = [ [[package]] name = "weaviate-client" -version = "4.22.0" +version = "4.23.0" source = { registry = "https://pypi.org/simple" } dependencies = [ { name = "authlib" }, @@ -1851,9 +1851,9 @@ dependencies = [ { name = "pydantic" }, { name = "validators" }, ] -sdist = { url = "https://files.pythonhosted.org/packages/34/2a/73cf7d6c7c6aa638738dfcb0d318e0404aab3c0673f82a1a4d89455b21a5/weaviate_client-4.22.0.tar.gz", hash = "sha256:0c50fbef546a522262a87d1138cde0509c7a8a48e702e967be33472e9f7fbae3", size = 860126, upload-time = "2026-06-18T06:08:30.202Z" } +sdist = { url = "https://files.pythonhosted.org/packages/20/9f/8bfe42e3c0693afa321fb712c0a1f1ff2b886059db33543120f6953dde8e/weaviate_client-4.23.0.tar.gz", hash = "sha256:19cc336b4c9e58f06cf01cb9aff8f6d8c0fe747f2e80192a9871c63823e8b18d", size = 873028, upload-time = "2026-08-13T14:23:08.112Z" } wheels = [ - { url = "https://files.pythonhosted.org/packages/e1/a3/27353ea3fbf9e7d4f03375176a838c632d009f5167d801adcbb5f6d3bd07/weaviate_client-4.22.0-py3-none-any.whl", hash = "sha256:ff2dbc8d1fc25739942402c22d1aba2350a16ba4a6b6ed0ba140689c70adf1d9", size = 652691, upload-time = "2026-06-18T06:08:28.622Z" }, + { url = "https://files.pythonhosted.org/packages/15/aa/8cafeb1c09901e8d220b00b771ffea35e5ea51db7d384dc85eff6cf667dc/weaviate_client-4.23.0-py3-none-any.whl", hash = "sha256:f17c645d22e1787e8fa4640e20fcfccdee39c81327af410c544a24c21d419e59", size = 656174, upload-time = "2026-08-13T14:23:06.583Z" }, ] [[package]] @@ -1908,7 +1908,7 @@ requires-dist = [ { name = "requests", specifier = ">=2.32.3" }, { name = "tqdm", specifier = ">=4.67.1" }, { name = "weaviate-agents", specifier = ">=1.7.0" }, - { name = "weaviate-client", specifier = "==4.22.0" }, + { name = "weaviate-client", specifier = "==4.23.0" }, { name = "weaviate-demo-datasets", specifier = ">=0.8.1" }, { name = "weaviate-engram", specifier = ">=0.3.0" }, ] From 9cc115e452a820965b2a4751a1f2e200fc7f1c09 Mon Sep 17 00:00:00 2001 From: Ivan Despot <66276597+g-despot@users.noreply.github.com> Date: Thu, 13 Aug 2026 17:24:53 +0200 Subject: [PATCH 2/4] docs: add and_cross to the BM25 concepts operator list The keyword-search concepts page still listed two search operators and asserted, as a general truth, that query tokens spread across different properties cannot match. Core v1.38.8 added a third operator that exists precisely to match tokens across properties. - Add and_cross to the operator list, with its tokenization/analyzer constraint and an "available from v1.38.8" qualifier, matching the phrasing already used on api/graphql/search-operators.md. - Reword the lead sentence to match search/bm25.md and search/hybrid.md, so "within a single searched property" describes what an operator can require rather than what all operators require. - Keep the worked example but scope its cross-property claim to `and`, and note that the same object does match under and_cross. Plain `and` is unchanged and still per-property; this is an addition, not a behaviour change. Co-Authored-By: Claude Opus 5 (1M context) --- docs/weaviate/concepts/search/keyword-search.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/weaviate/concepts/search/keyword-search.md b/docs/weaviate/concepts/search/keyword-search.md index 86c3a0ef9..53bebf4b6 100644 --- a/docs/weaviate/concepts/search/keyword-search.md +++ b/docs/weaviate/concepts/search/keyword-search.md @@ -136,13 +136,14 @@ import SearchOperators from '/_includes/feature-notes/search-operators.mdx'; -Search operators define the minimum number of query [tokens](../../search/bm25.md#set-tokenization) that must be present within a single searched property for an object to be returned. +Search operators define how many of the query [tokens](../../search/bm25.md#set-tokenization) must match, and whether they must all match within a single searched property. Conceptually, it works as though a filter is applied to the results of the BM25 score calculation. The available operators are: - `and`: All tokens must be present within a single searched property - `or`: At least one token must be present within a single searched property, with the minimum number of tokens being configurable (`minimumOrTokensMatch`) +- `and_cross`: Every token must be matched by at least one of the searched properties, so the tokens can be spread across different properties. All searched properties must share the same tokenization and analyzer settings, otherwise the query fails with an error. (available from `v1.38.8`) -As an example, a BM25 query of `computer networking guide` with the `and` operator would only return objects where all of the tokens `computer`, `networking`, and `guide` appear together within a single searched property. If the tokens are spread across different properties (for example, `computer` in `title` and `networking` in `description`), the object does not match under `and`. In contrast, the same query with the `or` operator would return objects where at least one of those tokens appears in a searched property. If the `or` operator is used with a `minimumOrTokensMatch` of `2`, then at least two of the tokens must be present within a single searched property. +As an example, a BM25 query of `computer networking guide` with the `and` operator would only return objects where all of the tokens `computer`, `networking`, and `guide` appear together within a single searched property. If the tokens are spread across different properties (for example, `computer` in `title` and `networking guide` in `description`), the object does not match under `and`. That restriction is specific to `and`; the same object does match under `and_cross`, which requires each token to appear in at least one of the searched properties rather than all of them in the same one. In contrast, the same query with the `or` operator would return objects where at least one of those tokens appears in a searched property. If the `or` operator is used with a `minimumOrTokensMatch` of `2`, then at least two of the tokens must be present within a single searched property. If not specified, the default operator is `or`, with a `minimumOrTokensMatch` of `1`. This means that at least one token must be present in a searched property for the object to be returned. From 39fbed4aae7378ce3caa5600bfbaadbe10641770 Mon Sep 17 00:00:00 2001 From: Ivan Despot <66276597+g-despot@users.noreply.github.com> Date: Thu, 13 Aug 2026 17:27:01 +0200 Subject: [PATCH 3/4] docs: finish the and_cross sweep on the two remaining pages Follow-up to 9cc115e4, which fixed only the keyword-search concepts page. - concepts/search/hybrid-search.md listed the operators as "and or or" in a passing mention of the BM25 parameters hybrid search inherits. Name and_cross alongside them and link the phrase to the concepts section that carries the semantics, keeping the mention at its original depth. - search/hybrid.md named and_cross under the shared "Added in v1.31" note with no qualifier of its own, so a v1.38.8 operator appeared to date from v1.31. Add the inline "(available from v1.38.8)" form used on api/graphql/search-operators.md and on the concepts page. The two-operator claim now appears nowhere under docs/. Co-Authored-By: Claude Opus 5 (1M context) --- docs/weaviate/concepts/search/hybrid-search.md | 2 +- docs/weaviate/search/hybrid.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/weaviate/concepts/search/hybrid-search.md b/docs/weaviate/concepts/search/hybrid-search.md index 181fe96b5..eeed33e5e 100644 --- a/docs/weaviate/concepts/search/hybrid-search.md +++ b/docs/weaviate/concepts/search/hybrid-search.md @@ -191,7 +191,7 @@ This is because BM25 scores are not normalized or bounded like vector distances, ## Keyword (BM25) search parameters -Hybrid search in Weaviate supports all the parameters available for keyword (BM25) search. This includes, for example, the ability to set the tokenization method, stopwords, BM25 parameters (k1, b), search operators (`and` or `or`), specific properties to search and/or to boost particular properties. +Hybrid search in Weaviate supports all the parameters available for keyword (BM25) search. This includes, for example, the ability to set the tokenization method, stopwords, BM25 parameters (k1, b), [search operators](./keyword-search.md#keyword-search-operators) (`and`, `or`, or `and_cross`), specific properties to search and/or to boost particular properties. For more information on these parameters, see the [keyword search page](./keyword-search.md). diff --git a/docs/weaviate/search/hybrid.md b/docs/weaviate/search/hybrid.md index 7f0f13176..50fecf2f4 100644 --- a/docs/weaviate/search/hybrid.md +++ b/docs/weaviate/search/hybrid.md @@ -387,7 +387,7 @@ import SearchOperators from '/_includes/feature-notes/search-operators.mdx'; -Keyword (BM25) search operators define how many of the query [tokens](#tokenization) must match, and whether they must all match within a single searched property. The options are `or` (default), `and`, and `and_cross`. +Keyword (BM25) search operators define how many of the query [tokens](#tokenization) must match, and whether they must all match within a single searched property. The options are `or` (default), `and`, and `and_cross` (available from `v1.38.8`). The keyword leg of a hybrid query accepts the same operators as a standalone keyword search. For `and_cross`, which matches every token across the searched properties combined, see [BM25 search: `and_cross`](./bm25.md#and_cross). From 1f039cfee0bfc81e99616a6aa0977e6758ccac1b Mon Sep 17 00:00:00 2001 From: Ivan Despot <66276597+g-despot@users.noreply.github.com> Date: Thu, 13 Aug 2026 17:47:35 +0200 Subject: [PATCH 4/4] chore: point the REST API reference at the v1-39 OpenAPI spec The interactive REST reference (@scalar/docusaurus at /weaviate/api/rest) was still pinned to the curated v1-38/openapi-for-docs branch. Bump the ref to v1-39/openapi-for-docs, which carries info.version 1.39.0. Verified by fetching the exact URL literal from the config: HTTP 200, 412645 bytes, valid Swagger 2.0. Against the 1.38 spec it adds /search/{collection}/near-text, the namespace suspend/resume pair and the property index rebuild/cancel pair, and drops /schema/{className}/indexes/{propertyName}. This pin is not covered by _build_scripts/update-config-versions.js, which only rewrites versions-config.json, so it is a manual per-release step. Co-Authored-By: Claude Opus 5 (1M context) --- docusaurus.config.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docusaurus.config.js b/docusaurus.config.js index 0d053915a..6450c6428 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -64,7 +64,7 @@ const config = { cdn: "https://cdn.jsdelivr.net/npm/@scalar/api-reference@1.49.0", configuration: { spec: { - url: "https://raw.githubusercontent.com/weaviate/weaviate/v1-38/openapi-for-docs/openapi-specs/schema.json", + url: "https://raw.githubusercontent.com/weaviate/weaviate/v1-39/openapi-for-docs/openapi-specs/schema.json", }, hideModels: true, showSidebar: true,