[SERVER-30505] Add generic idl type that represents any valid bson type Created: 03/Aug/17  Updated: 27/Oct/23  Resolved: 25/Aug/17

Status: Closed
Project: Core Server
Component/s: IDL, Internal Code
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Randolph Tan Assignee: Mark Benvenuto
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-30532 Add lastErrorObject.upserted to findA... Closed
Backwards Compatibility: Fully Compatible
Participants:

 Description   

Example use case:
findAndModify response includes a lastErrorObject.upserted field. This contains the value of the _id field of the upserted document. And since _id field can be any BSON type, the lastErrorObject.upserted field will also need to be able to do so.



 Comments   
Comment by Mark Benvenuto [ 25/Aug/17 ]

Resolving since SERVER-30532 will be handled by chained types.

Comment by Mark Benvenuto [ 21/Aug/17 ]

The AnyBasicType is just an example of how to use the 'any' type. The IDL contract is that it passes a custom C++ type a BSONElement for deserialization. It is the custom type's purpose how to handle the BSONElement, and its lifetime. For instance, if you assume the custom type will always outlive the BSONObj that owns the BSONElement, then you could simply store the BSONElement. If you do not want to make any assumptions about the BSONElement, you will need to store is value in different types like 'int' or 'std::string' or whatever type you actually expect the BSONElement to actually be.

Comment by Randolph Tan [ 20/Aug/17 ]

Forgot to tag mark.benvenuto on my comment above

Comment by Randolph Tan [ 20/Aug/17 ]

I think the AnyBasicType class can only be used safely in a very small use cases. This is because it just uses a BSONElement, which is like a view to an unowned memory. Therefore, the idl generated class that would be using this is valid only for the lifetime of the BSONObj where the BSONElement was created from. That means that it is not safe to store the idl object for later use and in a lot of cases, you can't even return the idl object because the BSON object would be destroyed when the function exits.

Comment by Mark Benvenuto [ 11/Aug/17 ]

Does the 'any' type meet your needs?

See https://github.com/mongodb/mongo/blob/master/src/mongo/idl/idl_test_types.h#L39-L66 for the C++ use case.

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