[SERVER-24485] Indicate Decimal128 is just the 128 version in extended JSON Created: 09/Jun/16  Updated: 06/Dec/22  Resolved: 15/Jun/16

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

Type: Improvement Priority: Minor - P4
Reporter: Derick Rethans Assignee: Backlog - Storage Execution Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Backwards Compatibility: Fully Compatible
Participants:

 Description   

While implementing HHVM-186 (Decimal128 support in the HHVM driver), bjori pointed out that I should name the class Decimal128 instead of Decimal.

When doing so, I noticed that the extended JSON representation, as well as the shell, do not include the specific type (128) either:

{ "field" : { "$numberDecimal" : "1234.5678" } }

Is there a reason why the "128" isn't included in either extendedJSON or shell wrapper object?



 Comments   
Comment by Geert Bosch [ 09/Jun/16 ]

From a server POV, it is extremely unlikely that we will ever add support for additional lower precision types. For a database that has to handle mixed datatypes, adding additional numeric types add significant complexity to comparison and indexing as adding a new numerical type doubles the number of type combinations. This is also the reason we never have added single precision binary floating point.

Note that there wouldn't be any significant space savings regardless: our keystring encoding in indexes already uses an 8 byte format for decimals with up to significant digits, and with our default compression storage size only increases by about 3 bytes for random decimal numbers, see SERVER-1393. Similarly, conversions and calculations can be (and to an extend have been) optimized for decimal numbers with few digits without requiring a new type.

Finally, having named our decimal type NumberDecimal does not by itself preclude adding a type with different precision. None of our existing numeric types include bit sizes in their name, so we wouldn't be completely consistent in naming regardless.

Comment by Asya Kamsky [ 09/Jun/16 ]

Let's get to consensus and be consistent by 3.3.9 release.

Comment by Jeffrey Yemin [ 09/Jun/16 ]

Including 128 in the name now would make it easier to add 32/64 bit decimal support in a future release.

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