[SERVER-6206] need a policy for incompatible types in operators in aggregation expressions Created: 25/Jun/12  Updated: 07/Apr/23  Resolved: 09/Nov/15

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

Type: Bug Priority: Major - P3
Reporter: Matt Dannenberg Assignee: Unassigned
Resolution: Duplicate Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-6203 Aggregation operators should have wel... Backlog
is duplicated by SERVER-11157 Type casting operator for aggregation... Closed
Related
related to SERVER-6165 use of an integer valued double with ... Closed
related to SERVER-6125 aggregation $sort cannot process hete... Closed
related to SERVER-6142 ExpressionCompare::evaluate does not ... Closed
related to SERVER-6184 mixing nested and dotted $project Exp... Closed
related to SERVER-6196 'can't add two dates together' assert... Closed
Operating System: ALL
Participants:

 Description   

We need to decide how we are going to handle cases where aggregation expressions do not have an obviously correct return type. For example, if the user applies $mod with a string or double as an argument, or if the user applies $add with a string and a date.



 Comments   
Comment by Charlie Swanson [ 09/Nov/15 ]

Closing as duplicate of SERVER-6203. Feel free to re-open and describe the differences between the two tickets if you see any.

Comment by Evan Altman [ 05/Jan/15 ]

In addition to error handling for mismatched/incompatible types, it could be beneficial to have a projection operator such as "$castString" or "$cast":

{type: <type>, value:<value>}

. We often cast ObjectIds to strings in our application code, but type casting could be useful elsewhere, too.

Generated at Thu Feb 08 03:11:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.