[SERVER-27601] Add support any types: uint, short, ushort, byte, sbyte ... etc Created: 07/Jan/17  Updated: 31/May/17  Resolved: 28/Feb/17

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

Type: New Feature Priority: Major - P3
Reporter: Vorobjev Valery Assignee: Andrew Morrow (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Participants:

 Description   

Please add more types in mongoDB. uint, short, ushort, byte, sbyte ... etc

Very often it makes no sense to store in the database data from the familiar. For example, the number of votes cannot be negative. Or, you need to store the value of the height of the ceiling. Why use an Int32, when you can do a byte type.



 Comments   
Comment by Andrew Morrow (Inactive) [ 14/Feb/17 ]

Hi boniface -

Thank you for filing this feature request. At this time, we are not considering such an expansion of the BSON types. There is considerable complexity involved in adding new types to BSON. We have only done so once since the early days of MongoDB, to implement support for the Decimal128 type introduced in MongoDB 3.4. In that case, the need was particularly pressing, since floating point values are simply not acceptable for some use cases, notably those involving currency, and the existing integral types cannot represent fractional values. The various workarounds for that issue imposed a significant burden on developers.

You appear to make two distinct arguments for adding new types, which I'll refer to as the 'compactness' argument, and the 'fidelity' argument, but I believe that in each case there is a more appropriate mechanism to achieve your aim.

  • For the compactness argument, I'd suggest that you will do overall better by just enabling compression in the storage engine. This will allow your keys and repeated data values (potentially including runs of zeros) to be compressed. This will happen transparently, without requiring that you try to optimize your document structure up front via the type system.
  • For the fidelity argument, I'd suggest that you look instead into using the document validation facility to enforce constraints. Encoding value constraints with the type system is much less expressive than using document validation.

Finally, I'll point out that adding new types (and, in particular, adding unsigned types), would complicate the semantics and implementation of arithmetic and comparison operations, with potential performance consequences for all types.

Our current view therefore is that there are good alternatives for both of the motivating cases, and therefore the implementation complexity and risk associated with adding these sorts of new types is not justified. If you have any thoughts on the above suggestions we are happy to continue the discussion.

Comment by Kelsey Schubert [ 09/Jan/17 ]

Hi boniface,

Thanks for the feature request – I've marked this ticket to be considered by the Storage Team.

Kind regards,
Thomas

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