[
https://issues.apache.org/jira/browse/UNOMI-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-1018:
-------------------------------
Description:
h3. Summary
On OpenSearch, an aggregate query that uses a date histogram or a numeric, date
or IP range returns no value buckets. The same query on Elasticsearch returns
the expected buckets. Terms aggregates (counts by a string property) work on
both engines.
The OpenSearch persistence layer builds these aggregations, but when it reads
the answer it only handles string-terms buckets. Other bucket types are
ignored, so the map of results has no entries for the date or range keys.
The goal of this ticket is that date and range aggregates return their buckets
on OpenSearch the same way they do on Elasticsearch.
h3. Ways to explore
* When reading the aggregation answer, handle the same bucket kinds
Elasticsearch already handles (for example date histogram, long terms, and the
range types Unomi supports).
* Add integration tests that run on both search engines for a date aggregate
and for a numeric range aggregate, and check the bucket keys and counts.
h3. How to test
On Elasticsearch and on OpenSearch, create a few profiles with known dates or
numeric properties, then send a date-histogram aggregate and a numeric-range
aggregate. Check that the answer lists the expected buckets and counts on both
engines. A terms aggregate must still work.
Correction: numeric, date and IP range aggregates also return no buckets on
Elasticsearch, because its result reader only handles multi-terms, string
terms, long terms and date histograms. The range fix is needed on both engines.
Date histogram and long terms are missing on OpenSearch only.
Also in scope (from UNOMI-1014): in
PersistenceServiceIT.testAggregateAndMetricsStayInTheCurrentTenant, add a check
that the other tenant sees only its own items: inside
executeAsTenant(otherTenant), aggregateQuery(null, byFirstName,
Profile.ITEM_TYPE).get("_all") must equal 2.
was:
h3. Summary
On OpenSearch, an aggregate query that uses a date histogram or a numeric, date
or IP range returns no value buckets. The same query on Elasticsearch returns
the expected buckets. Terms aggregates (counts by a string property) work on
both engines.
The OpenSearch persistence layer builds these aggregations, but when it reads
the answer it only handles string-terms buckets. Other bucket types are
ignored, so the map of results has no entries for the date or range keys.
The goal of this ticket is that date and range aggregates return their buckets
on OpenSearch the same way they do on Elasticsearch.
h3. Ways to explore
* When reading the aggregation answer, handle the same bucket kinds
Elasticsearch already handles (for example date histogram, long terms, and the
range types Unomi supports).
* Add integration tests that run on both search engines for a date aggregate
and for a numeric range aggregate, and check the bucket keys and counts.
h3. How to test
On Elasticsearch and on OpenSearch, create a few profiles with known dates or
numeric properties, then send a date-histogram aggregate and a numeric-range
aggregate. Check that the answer lists the expected buckets and counts on both
engines. A terms aggregate must still work.
> OpenSearch aggregate queries miss date and range buckets
> --------------------------------------------------------
>
> Key: UNOMI-1018
> URL: https://issues.apache.org/jira/browse/UNOMI-1018
> Project: Apache Unomi
> Issue Type: Bug
> Affects Versions: unomi-4.0.0
> Reporter: Serge Huber
> Priority: Major
> Fix For: unomi-4.0.0
>
>
> h3. Summary
> On OpenSearch, an aggregate query that uses a date histogram or a numeric,
> date or IP range returns no value buckets. The same query on Elasticsearch
> returns the expected buckets. Terms aggregates (counts by a string property)
> work on both engines.
> The OpenSearch persistence layer builds these aggregations, but when it reads
> the answer it only handles string-terms buckets. Other bucket types are
> ignored, so the map of results has no entries for the date or range keys.
> The goal of this ticket is that date and range aggregates return their
> buckets on OpenSearch the same way they do on Elasticsearch.
> h3. Ways to explore
> * When reading the aggregation answer, handle the same bucket kinds
> Elasticsearch already handles (for example date histogram, long terms, and
> the range types Unomi supports).
> * Add integration tests that run on both search engines for a date aggregate
> and for a numeric range aggregate, and check the bucket keys and counts.
> h3. How to test
> On Elasticsearch and on OpenSearch, create a few profiles with known dates or
> numeric properties, then send a date-histogram aggregate and a numeric-range
> aggregate. Check that the answer lists the expected buckets and counts on
> both engines. A terms aggregate must still work.
> Correction: numeric, date and IP range aggregates also return no buckets on
> Elasticsearch, because its result reader only handles multi-terms, string
> terms, long terms and date histograms. The range fix is needed on both
> engines. Date histogram and long terms are missing on OpenSearch only.
> Also in scope (from UNOMI-1014): in
> PersistenceServiceIT.testAggregateAndMetricsStayInTheCurrentTenant, add a
> check that the other tenant sees only its own items: inside
> executeAsTenant(otherTenant), aggregateQuery(null, byFirstName,
> Profile.ITEM_TYPE).get("_all") must equal 2.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
