[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:
Duplicate
duplicates SERVER-30417 add expression to get value by keynam... Closed
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:

{
    $addFields: {
        valueAtKey: {
            $let: {
                vars: { keyVals: { $objectToArray: '$someObjectField' } },
                in: {
                    $arrayElemAt: [
                        '$$keyVals',
                         { $indexOfArray: ['$$keyVals.k', '$someKeyField'] }
                    ]
                }
            }
        }
    }
}

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:

{
    $addFields: {
        valueAtKey: { $objectValueAt: ['$someObjectField', '$someKeyField'] }
    }
}

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 SERVER-30417 is actually identical to the proposal here, except the name is $getField and the argument order is reversed. In no proposal for this feature would the new expression accept only a literal string; there would always be a subexpression that must evaluate to an object and a subexpression that must evaluate to a string. Furthermore, our process is to design the precise syntax and semantics of a new MongoDB Query Language feature only when that feature is slated for development. The fixVersion of "Backlog" for SERVER-30417 indicates that it is not currently scheduled for work.

I'm resolving this ticket as a duplicate of SERVER-30417. Please vote for it and watch if for updates.

Best,
Dave

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 SERVER-30417, which I suggest you watch and vote for. Can you confirm that this is indeed a dup?

Thanks,
Dave

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