[SERVER-29596] Allow projection of one or multiple ObjectID sub-components. Created: 12/Jun/17  Updated: 06/Apr/23

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

Type: New Feature Priority: Minor - P4
Reporter: Dissatisfied Former User Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Optimization
Participants:

 Description   

In a similar, though more generalized vein to SERVER-9406 (treating ObjectIDs as dates) and SERVER-24947 (to- typecasting mechanisms), allowing for the projection of any (or all) sub-component(s) of an ObjectId into discrete fields would allow for easy additional processing on these values. Practical use case: aggregate group results based on machine (hardware ID ± PID) that generated the record, useful for log or other hardware-dependent statistical analysis.

The syntax recommendation comes in two forms, short single-component, or multi-component embedded document:

{$project: {parts: {$decomposeId: {_id: true}}}

This would project all components from an ObjectId into an embedded document named parts:

{parts: {ts: ISODate, host: int, pid: int, counter: int}

To retrieve specific values, pass a document instead of true:

{$project: {parts: {$decomposeId: {_id: {host: true, pid: true}}}

{parts: {host: int, pid: int}

To retrieve a specific singular value, pass just its name instead of true:

{$project: {created: {$decomposeId: {_id: "ts"}}}

{created: ISODate(...)}

As mentioned in the first paragraph, this is to facilitate use of group operations on ObjectID components. As a side-effect, this would have also resolved SERVER-9406. (Though automatic casting is nice, explicit is better than implicit.)



 Comments   
Comment by Dissatisfied Former User [ 25/Jun/17 ]

While it's most common for "_id" to be of type ObjectId, any expression to convert ObjectId to another type would have to work on any arbitrary field that happens to be ObjectId type as well.

I continue to set my expectations too high. Not sure what part of this offers the restriction you seem to imagine is present:

{$project: {created: {$decomposeId: {_id: "ts"}}}

It's literally:

{$project: {TARGET: {$decomposeId: {SOURCE: COMPONENTS}}}

This means that no, it's not restricted to the _id field:

{$project: {created: {$decomposeId: {someid: true}}}

Pretend "someid" there is "$someid" (…an arbitrary expression…) if need be. After the fourth time failing to read, but still commenting, I just have to assume you're trolling; which is amazing. Edited to add: unwatched. Do what you will.

Comment by Asya Kamsky [ 25/Jun/17 ]

amcgregor thanks for the suggestion. We would need to figure out syntax that accepts the expression for the field to be decomposed. While it's most common for "_id" to be of type ObjectId, any expression to convert ObjectId to another type would have to work on any arbitrary field that happens to be ObjectId type as well.

Comment by Dissatisfied Former User [ 12/Jun/17 ]

To throw in a solution for SERVER-29512 as well, passing false instead of true could totally return the ID as a hex-encoded string… four tickets, one solution. ;P

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