stonedb
stonedb copied to clipboard
bug:A table of type DECIMAL, inserting a maximum value, displayed as 0
Describe the problem A table of type DECIMAL, inserting a maximum value, displayed as 0
Expected behavior The expected values are 9999999999999999999999999999.9999999999、-9999999999999999999999999999.9999999999
How To Reproduce Execute to create tables of type DECIMAL
Create Table: CREATE TABLE `TYPE008` (
`COL` decimal(18,10) DEFAULT NULL
) ENGINE=STONEDB DEFAULT CHARSET=utf8
Perform the maximum value of the insert DECIMAL (38,10) type. Perform insert minimum values of type DECIMAL (38,10)
INSERT INTO TYPE008 VALUES(99999999.9999999999);
INSERT INTO TYPE008 VALUES(-99999999.9999999999);
SELECT * FROM TYPE008;
Environment Ubuntu 20.04.4 LTS Server version: 5.6.24-StoneDB
Additional context none
FIx it in stonedb-5.7 first.
Stonedb decimal bug fix && support completely "decimal data type":
- Problem Description:
This problem is because when the bottom layer of stonedb stores the type of decimal, it needs to convert the decimal into int64_t type storage according to the scale parameter. In the process of conversion, the my_strtod() function is used, resulting in loss of precision.
The precision range problem, because the bottom layer uses int64_t storage, the precision range is limited to 18 bits, which is less than the 65 bits of the decimal data type supported by innodb.
- Current solution:
Encoding and storage: stonedb supports two storage types, PackInt and PackStr. At present, the storage scheme of PackStr can be used, and the encoding scheme of decimal of innodb is adopted: convert to Fixed Binary String <my_decimal2binary>, and the bottom layer is stored in binary string.
Operator, aggregation function adaptation in stonedb: read binary string from the bottom layer, convert it to decimal type, and support operations such as decimal type comparison. Various operators, functions, and operators of stonedb need to support the decimal type.
Any Questions?
relate to #456, change it to feature.