From 03cfbacafacdf10e761785fb77afcbebd61b7113 Mon Sep 17 00:00:00 2001 From: Dominik Schmidt Date: Wed, 1 Jul 2026 19:49:05 +0200 Subject: [PATCH] docs(adr): add concrete mtime/name backend-drift examples --- docs/adr/0005-unified-search-index-mapping.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/docs/adr/0005-unified-search-index-mapping.md b/docs/adr/0005-unified-search-index-mapping.md index 93cd4305a4..3e3024f01f 100644 --- a/docs/adr/0005-unified-search-index-mapping.md +++ b/docs/adr/0005-unified-search-index-mapping.md @@ -41,7 +41,16 @@ The current implementation has four concrete problems: declared. The inferred shapes differ: bleve produces keyword- analyzed text, OpenSearch produces a `text + keyword` multi-field with auto-detected dates. Nobody has written down which behavior - is the intended one. + is the intended one. Two concrete instances surfaced while building + #2659: + - **mtime** is stored as an RFC3339 string. OpenSearch's dynamic + mapping auto-detects it as `date`; bleve leaves it `keyword`. So + `mtime:>...` is a chronological range on OpenSearch but a + lexicographic string compare on bleve. + - **name/tags**: bleve indexes a single lowercase token (exact or + wildcard match only); OpenSearch word-tokenizes, so a bare + `name:report` matches "My Report.txt" on OpenSearch but not on + bleve. 2. **The indexed facet metadata is effectively unreachable.** The audio, image, photo and location sub-fields go into the index and take up space, but no caller of the search service can actually