Repository navigation
Conversation
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 407 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
dschmidt
force-pushed
the
feat/graph-search-query
branch
from
August 18, 2026 16:51
1b61ef6 to
fb1e41b
Compare
dschmidt
force-pushed
the
feat/search-geohash-aggregation
branch
from
August 18, 2026 17:00
59aacc8 to
c775513
Compare
dschmidt
force-pushed
the
feat/graph-search-query
branch
9 times, most recently
from
September 3, 2026 08:33
2513263 to
71ca404
Compare
dschmidt
force-pushed
the
feat/search-geohash-aggregation
branch
from
September 7, 2026 22:14
c775513 to
2d46411
Compare
1 task done
dschmidt
added a commit
that referenced
this pull request
Sep 8, 2026
The same tokenizer with tag_depth turns a geohash into depth-tagged prefixes, so a terms facet with TermPrefix is a geohash grid at that precision. One location_geohash field per geopoint, part of the v5 schema so #3272 needs no further bump. OpenSearch maps it unindexed, geohash_grid works on the geo_point.
dschmidt
added a commit
that referenced
this pull request
Sep 10, 2026
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469). Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped. The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
dschmidt
added a commit
that referenced
this pull request
Sep 10, 2026
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469). Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped. The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
1 task done
dschmidt
added a commit
that referenced
this pull request
Sep 10, 2026
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469). Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped. The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
dschmidt
added a commit
that referenced
this pull request
Sep 10, 2026
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469). Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped. The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
dschmidt
added a commit
that referenced
this pull request
Sep 10, 2026
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469). Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped. The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
OpenSearch buckets a geohash_grid aggregation on the geo_point itself, bleve has no such aggregation. bleve now maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into depth-tagged prefixes, so a terms facet with TermPrefix "<precision>/" is the grid at that precision (#3272). Only bleve knows the field, the shared document shape and OpenSearch are untouched; the mapping change is additive.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into depth-tagged prefixes, so a terms facet with TermPrefix "<precision>/" is a geohash grid (#3272). bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into depth-tagged prefixes, so a terms facet with TermPrefix "<precision>/" is a geohash grid (#3272). bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
force-pushed
the
feat/graph-search-query
branch
from
September 11, 2026 14:30
fef1116 to
7f7ecbf
Compare
dschmidt
added a commit
that referenced
this pull request
Sep 11, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
force-pushed
the
feat/search-geohash-aggregation
branch
from
September 11, 2026 14:33
2d46411 to
d7bdce8
Compare
dschmidt
changed the title
dschmidt
changed the base branch from
feat/graph-search-query
to
feat/search-bleve-geohash-sibling
September 11, 2026 14:33
dschmidt
added this pull request to stack #3520
September 11, 2026 14:34
Generated from opencloud-eu/libre-graph-api#34 rebased onto main: POST /search/query with hits, aggregations and metrics.
MS-Graph-style search query endpoint: hits from all accessible spaces, with from/size paging, remote items for hits from shared spaces, thumbnails on $expand, and the effective permission actions on every hit. The search proto gains the aggregation types of the graph API and the endpoint passes aggregations through to the search service, which does not evaluate them yet.
dschmidt
added a commit
that referenced
this pull request
Sep 12, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
force-pushed
the
feat/search-bleve-geohash-sibling
branch
from
September 12, 2026 15:34
f017713 to
9b4883b
Compare
dschmidt
force-pushed
the
feat/search-geohash-aggregation
branch
from
September 12, 2026 15:34
d7bdce8 to
c65b323
Compare
dschmidt
added a commit
that referenced
this pull request
Sep 12, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
force-pushed
the
feat/search-bleve-geohash-sibling
branch
from
September 12, 2026 15:38
9b4883b to
3d449df
Compare
dschmidt
force-pushed
the
feat/search-geohash-aggregation
branch
from
September 12, 2026 15:38
c65b323 to
ffbdf81
Compare
dschmidt
added a commit
that referenced
this pull request
Sep 12, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
force-pushed
the
feat/search-bleve-geohash-sibling
branch
from
September 12, 2026 16:23
3d449df to
f0f9fce
Compare
dschmidt
force-pushed
the
feat/search-geohash-aggregation
branch
from
September 12, 2026 16:23
ffbdf81 to
db0b7b1
Compare
Term buckets on both engines: bleve facets, OpenSearch terms aggregations, buckets merged across spaces and post-processed per BucketDefinition (minimum count, sort, size). Terms aggregations on numeric fields are rejected at the graph endpoint. Pinned in the parity suite as AGG-01 to AGG-03. Ranges, metrics and sub-aggregations are declined until the engines evaluate them.
Numeric and date ranges on both engines: bleve numeric and date-time range facets, OpenSearch range and date_range aggregations, a bound that is neither number nor date is rejected. A terms aggregation on a numeric field now points to ranges as the alternative. AGG-04, 05 and 07 to 09 in the parity suite.
Sum, min, max and avg on both engines. bleve facets cannot compute, so a collector hooked into the document-match handler folds the metric from doc values, one pass over every match, before the top-n cut. Avg travels as sum and count so the service can reduce it across spaces. AGG-06 in the parity suite.
Sub-aggregations on both engines. bleve folds child buckets from doc values through the same collector as the metrics, terms and ranges alike; the service unions nested buckets across spaces. AGG-10 to AGG-16 in the parity suite.
Every bucket carries an opaque aggregationFilterToken; a search request can pass tokens back as aggregationFilters. The service decodes them into KQL fragments once, the engines AND them into the query as exact, case-sensitive matches.
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
(cherry picked from commit 0cfe3b8)
A geohash_precision aggregation runs as a terms facet on the geohash sibling of the geopoint, restricted to the terms tagged with the requested precision; nested, it folds the same terms from doc values. The cells match OpenSearch's geohash_grid, pinned in the parity suite.
dschmidt
force-pushed
the
feat/search-bleve-geohash-sibling
branch
from
September 12, 2026 16:34
f0f9fce to
96dd924
Compare
dschmidt
force-pushed
the
feat/search-geohash-aggregation
branch
from
September 12, 2026 16:34
db0b7b1 to
fbc1806
Compare
dschmidt
removed this pull request from stack #3520
October 5, 2026 06:48
dschmidt
added a commit
that referenced
this pull request
Oct 6, 2026
bleve maps a <name>_geohash field next to every geopoint field and writes the geohash from the batch, analyzed into one depth-tagged term per precision. Groundwork for a geohash grid on bleve (#3272), nothing queries it yet. bleve only, additive on the v5 schema.
dschmidt
force-pushed
the
feat/search-bleve-geohash-sibling
branch
from
October 6, 2026 09:24
96dd924 to
58c52b7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
AggregationOption.geohash_precision(1-12) turns an aggregation on a geopoint field into a geohash grid: bucket key is the cell, value the doc count. Rejected on non-geo fields and precisions beyond 12.geohash_gridon the geopoint sibling.Stacked on #3211 and #3519. No mapping change.
How Has This Been Tested
Types of changes