-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Query Integration
-
QI 2023-05-29, QI 2023-06-12, QI 2023-06-26, QI 2023-07-10, QI 2023-07-24, QI 2023-08-07, QI 2023-08-21, QI 2023-09-04, QI 2023-09-18, QI 2023-10-02, QI 2023-10-16, QI 2023-10-30, QI 2023-11-13, QI 2023-11-27, QI 2023-12-11, QI 2023-12-25, QI 2024-01-08, QI 2024-01-22, QI 2024-02-05, QI 2024-02-19, QI 2024-03-04, QI 2024-03-18, QI 2024-04-01, QI 2024-04-15, QI 2024-04-29, QI 2024-05-13, QI 2024-05-27
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
-
None
db.createCollection(
coll.getName(),
{timeseries: {timeField: 'time', metaField: 'meta'}, collation: {locale: "en_US", numericOrdering: true, strength: 1}});
// The 'numericOrdering' on the collection means that the max of the bucket with the three docs
// below is "10" (while the lexicographic max is "5").
coll.insert({time: ISODate(), meta: 42, value: "1"});
coll.insert({time: ISODate(), meta: 42, value: "10"});
coll.insert({time: ISODate(), meta: 42, value: "5"});
// Should match "5" in lexicographic ordering.
coll.find({value: {$gt: "4"}}).collation({locale: "en_US", strength: 1});
However, the query returns no results on sharded collection. This happens because the pipeline is optimized first on mongos, which isn't aware of potential collation mismatch, so it pushes the filter as {"control.max.value": {"$_internalExprGt" : "4"}} and ends up skipping the bucket when the filter is executed with non-numericOrdering collation.
After this bug is fixed, jstests/core/timeseries/nondefault_collation.js should be re-enabled in sharded suites.
- is related to
-
SERVER-73024 Re-enable time-series sharded passthrough suites
-
- Closed
-