Skip to content

feat(search): geohash grid aggregation option - #62

Draft
dschmidt wants to merge 10 commits into
feat/searchfrom
feat/search-geohash-aggregation
Draft

feat(search): geohash grid aggregation option#62
dschmidt wants to merge 10 commits into
feat/searchfrom
feat/search-geohash-aggregation

Conversation

@dschmidt

Copy link
Copy Markdown
Contributor

Adds geohashPrecision to aggregationOption: when greater than 0 the aggregation becomes a geohash-grid aggregation over a geo-point field, each bucket keyed by a geohash cell plus its count. Libregraph extension not present in MS Graph.

Implementation: opencloud-eu/opencloud#3272
Stacked on #34.

dschmidt added 10 commits April 10, 2026 11:49
Added a new search endpoint for querying resources with detailed request and response structures, including examples for various search scenarios.

Based on the MS Graph Search Api of course: 

https://learn.microsoft.com/en-us/graph/api/resources/search-api-overview?view=graph-rest-1.0
The MS Graph token is opaque and varies by bucket type (hex-encoded for
terms, range(...) for ranges, with different quoting rules). Rather than
commit to that contract, omit the field and let clients construct
filters directly from field + key (or the original range definition).
Adds `subAggregations` as an optional array on both the request
(`aggregationOption`) and response (`searchBucket`) sides of the
search aggregation spec. Lets callers nest term aggregations, e.g.
"group by audio.artist, then by audio.album", evaluated in a single
request.

Explicit libregraph extension beyond MS Graph. Bleve backend emulates
via client-side fold over matched hits; OpenSearch would translate to
native composite aggregations.
Adds `metricKind` (sum|min|max) to aggregationOption and mirrors
`value` + `metricKind` on searchAggregation. When set, the
aggregation returns a scalar rather than a bucket list; `size` and
`bucketDefinition` are ignored. Libregraph extension, not present in
MS Graph.

Composable with subAggregations: a metric appears alongside term
sub-aggregations inside a parent bucket's subAggregations list, just
like in Elasticsearch. The most common use is "for each term bucket,
compute a scalar over a numeric field in that bucket's docs", e.g.
sum(audio.duration) per audio.album gives total album runtime.

Intentionally omits avg/cardinality: avg needs split (sum, count)
transport to merge correctly across shards and lands in a follow-up;
cardinality is already derivable from a terms sub-aggregation's
bucket count.
Adds `avg` as a permitted value on `aggregationOption.metricKind` and
`searchAggregation.metricKind`. Distinct from sum/min/max because an
average of two averages isn't mergeable: the backend has to carry
(sum, count) internally per bucket and only collapse to the scalar
`value` at the outermost merge.

Wire shape stays symmetrical with sum/min/max: callers still just
read `value` off the response; the (sum, count) bookkeeping is
entirely service-side.
Adds `geohashPrecision` to aggregationOption: when greater than 0 the
aggregation becomes a geohash-grid aggregation over `field` (which
must resolve to a geo-point field such as `location`). Each returned
searchBucket carries a geohash cell as key plus its count, suitable
for density/heatmap rendering. Libregraph extension not present in
MS Graph.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant