[COMPASS-7471] Investigate changes in SERVER-39336: In order to be schema friendly, $mod output should be based only on input types, not values Created: 20/Nov/23 Updated: 28/Nov/23 Resolved: 28/Nov/23 |
|
| Status: | Closed |
| Project: | Compass |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | No version |
| Type: | Investigation | Priority: | Major - P3 |
| Reporter: | Backlog - Core Eng Program Management Team | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Documentation Changes: | Not Needed | ||||||||
| Description |
|
Original Downstream Change Summary The type of the result of a $mod expression is now determined solely from the input types; the exact input value will no longer lead to a narrower result type. E.g., Previously $mod: [2, 1.1] would result in a double result, but $mod: [2, 1.0], would result in a integer, as the rhs happens to be convertible to an int without rounding error despite being of double type. Now, the result type will always be the wider of the two input types. If the existing behaviour was relied upon, users may now find that code expecting an int instead of a long or double needs to be updated to expect the appropriate type result - or to provide arguments as ints if applicable. Description of Linked Ticket $mod has a special condition if the right-hand-side is of non-integral type but of integral value. |
| Comments |
| Comment by Rhys Howell [ 28/Nov/23 ] |
|
No devtools impact |
| Comment by PM Bot [ 20/Nov/23 ] |
|
Fix Version updated for upstream |