This change makes it so that SBE does not short circuit on null. That is, it evaluates all of its arguments before checking whether they are null or arrays.
Description of Linked Ticket
In SBE, for almost all aggregate operators, all of the operator's arguments are evaluated first before doing typechecking or anything else. This was an intentional design decision.
From what I can tell, the only aggregate operators that intentionally have "short-circuit" style behavior are as follows:
- $and - Short-circuits evaluation of the remaining arguments when an argument evaluates to false (or something that when coerced to boolean will produce "false")
- $or - Short-circuits evaluation of the remaining arguments when an argument evaluates to true (or something that when coerced to boolean will produce "true")
- $switch - Short-circuits evaluation of the remaining case/then's when a case evaluates to true (or something that when coerced to boolean will produce "true")
- $ifNull - Short-circuits evaluation of the remaining arguments when an argument evaluates to a value that is not null/missing
Aside from the operators listed above, unless there is a specific reason, each aggregate operator's arguments should be evaluated first before doing anything else.
I noticed that the SBE implementation of $concatArrays seems to exhibit "short-circuit on null" behavior. Here is an example that demonstrates this:
> db.adminCommand({setParameter: 1, internalQueryEnableSlotBasedExecutionEngine: true}); { "was" : false, "ok" : 1 } > db.c.find() {_id: 1, a: null, b: "foo"} > db.c.aggregate([{$project: {x: {$concatArrays: [[1,2], "$a", {$add: [1,"$b"]}]}}}]) {_id: 1, x: null}
The goal of this task is to determine if $concatArrays in SBE should evaluate all of its arguments first before doing typechecking or anything else, and if so, to update the SBE implementation of $concatArrays accordingly.
- documents
-
SERVER-59785 [SBE] Change $concatArrays to not short-circuit on null
- Closed