[SERVER-38463] Add $objectValueAt Expression Created: 07/Dec/18 Updated: 06/Dec/22 Resolved: 11/Dec/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Jeffrey Mariconda | 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 |
|
There is currently no object analog to the $arrayElemAt expression that would allow you to easily access an object value at a variable key returned by an expression. Because of this, the most direct way to achieve this in a single step is to do the following:
This seems really roundabout and, on top of that, it actually returns the { k: ..., v: ... } object, so either another nested $let or a following $addFields stage would be needed if you just wanted the value.
It would be much more ideal, if possible, to be able to do something similar syntax-wise to $arrayElemAt like the following:
This would, ideally, resolve directly to the value if found and null otherwise. There would probably also need to be an error case, similar to $arrayElemAt, when the second argument does not resolve to a string. |
| Comments |
| Comment by David Storch [ 11/Dec/18 ] |
|
Thanks jeffm24. I believe the proposed syntax in I'm resolving this ticket as a duplicate of Best, |
| Comment by Jeffrey Mariconda [ 10/Dec/18 ] |
|
Oh wait, I didn't realize that the proposed syntax there was [<field name>, <object expression>]. To be honest, though, this is even more incongruous with similar existing expression syntax... |
| Comment by Jeffrey Mariconda [ 10/Dec/18 ] |
|
Ah ok it does seem to pretty much be a duplicate. I tried searching for it but it seems like our naming ideas were a bit different. The main distinction, as far as I can see, is that the first arg of that one seems to only accept a string field name, rather than an expression that results in an object. I think my proposal here would probably be more consistent with $arrayElemAt if it's supposed to be the object analog to that. |
| Comment by David Storch [ 10/Dec/18 ] |
|
Hi jeffm24, Thanks for filing this feature request! This looks like a duplicate of Thanks, |