[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: |
|
||||||||
| 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.
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-10682 (actually most of its duplicates are asking for this) | ||||
| 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.
Could still be caught statically, but a
Could not. Interestingly, this would allow for a
| ||||
| Comment by Patrick Meredith [ 22/Apr/19 ] | ||||
|
Something such as
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? |