Keyword and path fields always index their case-preserved base and, when CaseInsensitive is set, an additional <field>_lowercase sibling used only for matching. The KQL lowering marks a restriction case-insensitive; each backend searches the sibling and lowercases the query value the same way the sibling is precomputed at index time (Go strings.ToLower on both sides, so non-ASCII stays consistent).
Search always returns the case-preserved base, so the sibling never has to be read back. In bleve it is indexed but not stored, kept out of _all, and without doc values. In OpenSearch it deliberately stays in _source: excluding it would make every update-by-query script rebuild all siblings from the document via painless toLowerCase, which lowercases differently than Go and would drift from the query side. Keeping it in _source avoids that, and a lowercased copy of a name or path is negligible disk in a cluster.
The OpenSearch move script keeps the base and its sibling in sync by swapping the moved prefix in Path_lowercase and setting Name_lowercase from Go-lowercased params, so case-insensitive search still finds a file after it moves (previously the sibling went stale). bleve re-indexes the whole document on move/delete/restore, so its siblings stay fresh for free.
This also repairs OpenSearch path search (the query value was no longer folded to lowercase, so path:<Foo> returned nothing) and makes bleve path queries match a folder and its descendants like OpenSearch's path_hierarchy. The Path base stays case-preserved so the move/delete descendant update (an exact TermQuery on Path) matches mixed-case folders.
The KQL parser produced its own validation errors but imported them from the
search service's query package. Move them into pkg/kql and let the search
backend consume kql.IsValidationError, so the parser stops depending on a
service package.
* add support for specifying a basepath using -p when running the
posixfs scan command, to indicate a directory under which to start
scanning, or a singular file to scan, as opposed to scanning from the
storage root directory as is the default behaviour
* implements https://github.com/opencloud-eu/opencloud/issues/3182
This fixes the server-side translations for "activties" and e.g. the
default space description. We need to bump "leonelquinteros/gotext"
to latest master for that as even the latest release still contains
and issue that cause `go vet` to complain about non-constant
format strings.
Fixes: #2833, #2835
The base logger created by log.Configure already attaches a "service"
field via its context. handleProbe added it a second time, producing
JSON log entries with two "service" keys. Remove the redundant
Str("service", name) and the now-unused name parameter.
Four cases covering the distinct grammar paths touched by the
new Key rule: dotted key in a TextPropertyRestrictionNode,
multi-level key (stressing the Kleene part), dotted key in a
GroupNode (the k:Key? branch), and a dot on the value side
that must stay a literal character.
Introduce a dedicated Key rule (Char+ ("." Char+)*) so property
restriction keys can contain dots. Queries like
audio.artist:Motörhead or photo.cameraMake:Apple now parse.
Goal: keep the data structure aligned with the query namespace.
A driveItem exposes nested fields as dotted paths in its API
response (photo.cameraMake, location.latitude); users should be
able to query with the same path, without admin-configured slot
mappings or alias tables like Microsoft requires.
Both bleve and OpenSearch already treat dots as the nesting
separator for field paths and pass unknown keys through
unchanged — only the KQL grammar blocked dotted keys via
Char <- [A-Za-z]. The new Key rule lifts that restriction; no
compiler changes or field-alias maintenance is needed.
Values are unaffected — dots in values still parse as literal
characters.
be careful, the env:OC_EDITION, env:FRONTEND_EDITION, and conf:edition got removed as part of this commit, no deprecation because the flag is build time only!
Dominik Schmidt