[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.
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, |