[SERVER-40521] Add multi-type IDL types to the IDL parser Created: 08/Apr/19  Updated: 28/Jan/21  Resolved: 28/Jan/21

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

Type: Improvement Priority: Major - P3
Reporter: Ted Tuckman Assignee: A. Jesse Jiryu Davis
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-51369 Add "variant" type to IDL syntax Closed
Sprint: Security 2019-04-22, Query 2019-07-15, Query 2019-07-29, Query 2019-08-12
Participants:

 Description   

We've run into cases a couple times now where commands can take an argument that is one of two types (ex: Object or string). It would be useful if there was a way in IDL to express this, instead of having to create a new CPP class to represent that object for the IDL.



 Comments   
Comment by Ted Tuckman [ 01/Jul/19 ]

mark.benvenuto This has come up again, could we reopen this discussion? I've forgotten if we discussed why IDL could not do the parsing code for multi types using stdx::variant.

jacob.evans

Comment by Mark Benvenuto [ 22/Apr/19 ]

After offline discussions with ted.tuckman, my proposed change would not be sufficient for his needs. I am closing this as "Works As Designed".

Comment by Mark Benvenuto [ 15/Apr/19 ]

The IDL has a support for a union of scalar types but a union of any two of (object, array, scalar). I could add support for union of (object, and one or more scalars) but you would still need to write a C++ class to do the actual parsing. The IDL would only be able to guarantee that type checking was done before calling the C++ deserializer like it does today. See safeInt64 for an example.

Comment by Mira Carey [ 08/Apr/19 ]

We've got 5 users of stdx::variant at this point, so I'd suggest making that the backing data type if we decide to pursue this feature.

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