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