[SERVER-40494] Aggregation Framework does not have referential transparency for function calls Created: 05/Apr/19  Updated: 06/Dec/22  Resolved: 21/Jun/19

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

Type: Improvement Priority: Minor - P4
Reporter: Patrick Meredith 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-31991 Allow n-ary aggregation expressions t... Backlog
Assigned Teams:
Query
Participants:

 Description   

This is a problem that extends to all functions in the aggregation framework, both those that expect positional arguments in the form of arrays, and those that expect named arguments in the form of objects. Fixing this issue will be fairly labor intensive, and it is not a critical improvement; it just limits the amount of partial redundancy elimination we can do when optimizing pipelines.

db.foo.aggregate({$project: {out: {$let: {vars: {x: [1,2]}, in: {$add: "$$x"}}}}})
2019-04-02T14:21:18.263-0400 E QUERY    [js] Error: command failed: {
       "ok" : 0,
       "errmsg" : "$add only supports numeric or date types, not array",
       "code" : 16554,
       "codeName" : "Location16554"
} : aggregate failed :

This occurs because the parse methods for the individual expressions check for arrays and objects/specific object keys statically before the pipeline runs, so addressing this will also lose us some of our static checking capabilities.



 Comments   
Comment by Patrick Meredith [ 20/Jun/19 ]

asya SERVER-31991 shows asks for the same thing without showing the same issue. I am fine with merging these as duplicate.

Comment by Asya Kamsky [ 02/May/19 ]

patrick.meredith are these tickets examples of what you are talking about:  

SERVER-31991

SERVER-10682 (actually most of its duplicates are asking for this)

SERVER-30547
 

Comment by Patrick Meredith [ 22/Apr/19 ]

Also, I just realized we could still maintain some of the static checking, if we just relax the parser to allow variables in array/object positions.
It would give us the best of both worlds, as we could still report errors when someone does something statically wrong, such as

$cond

with a "foo" field:

{$cond: {if: true, then: false, else: true, foo: 'hello'}}

Could still be caught statically, but a

{$cond: '$$var'}

Could not. Interestingly, this would allow for a

$cond

that uses both array and object form in one query, dynamically changing.

Comment by Patrick Meredith [ 22/Apr/19 ]

Something such as

{$subtract: [
  {$add: [1,2,3]}, 
  {$multiply: [1,2,3]}
]} 

And note that [1,2,3] could actually be arbitrarily complex, rather than just an array of integers.

Comment by Craig Homa [ 22/Apr/19 ]

Hey patrick.meredith do you happen to have any example of where this limits the amount of partial redundancy elimination?

Generated at Thu Feb 08 04:55:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.