[SERVER-42957] An empty user-defined collation is ignored for aggregate commands Created: 21/Aug/19  Updated: 06/Dec/22  Resolved: 22/Aug/19

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Nicholas Zolnierz Assignee: Backlog - Query Team (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-25924 All commands that take a collation pa... Backlog
Assigned Teams:
Query
Participants:

 Description   

When parsing an aggregation request, the user supplied collation is parsed and stored on the AggregationRequest. However there is an assumption later in execution that an empty BSONObj for the collation implies that it was never set. For instance, here when resolving the collator to use for the operation. In this case, we'll end up incorrectly using the collection-default collation.



 Comments   
Comment by Charlie Swanson [ 22/Aug/19 ]

Best motivation I can see is to avoid developer confusion. Which seems good enough to keep a ticket open on the backlog about. It seems generally confusing and a bad practice to store something optional in a regular BSONObj when many people could without research assume that an empty collation means "binary comparisons" (as I did before looking it up on the most recent code review).

Comment by David Storch [ 22/Aug/19 ]

If I understand correctly, this duplicates SERVER-25924, which I recently closed as "Won't Do". Also, this behavior isn't specific to aggregate; I think it applies to most (or all?) of the read commands. Is it important to stop treating the empty object to mean the same thing as the absence of the collation argument?

Comment by Charlie Swanson [ 21/Aug/19 ]

Worth noting that our docs mention that the 'locale' argument is required, so this should probably be rejected at parse time.

Generated at Thu Feb 08 05:01:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.