[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: |
|
||||||||
| 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. |