Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug:A table of type DECIMAL, inserting a maximum value, displayed as 0 #103

Closed
422351990 opened this issue Jun 24, 2022 · 3 comments
Closed
Assignees
Labels
A-bug Something isn't working A-feature feature with good idea B-storage data type, data storage, insert,update,delete, transactions C-stonedb-5.7 associated with stonedb 5.7 prio: high High priority

Comments

@422351990
Copy link

422351990 commented Jun 24, 2022

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

@422351990 422351990 added the A-bug Something isn't working label Jun 24, 2022
@hustjieke hustjieke added the prio: high High priority label Jul 17, 2022
@RingsC RingsC added C-stonedb-5.6 associated with stonedb 5.6 C-stonedb-5.7 associated with stonedb 5.7 labels Jul 19, 2022
@hustjieke hustjieke added this to the stonedb_5.7_v1.0.0 milestone Jul 29, 2022
@hustjieke
Copy link
Collaborator

FIx it in stonedb-5.7 first.

@swoapri
Copy link

swoapri commented Aug 4, 2022

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?

@hustjieke hustjieke removed the C-stonedb-5.6 associated with stonedb 5.6 label Aug 30, 2022
@RingsC RingsC assigned duanfuxiang0 and konghaiya and unassigned swoapri and duanfuxiang0 Oct 14, 2022
@konghaiya konghaiya assigned duanfuxiang0 and unassigned konghaiya Oct 19, 2022
@RingsC RingsC assigned hustjieke and unassigned duanfuxiang0 Nov 29, 2022
@wisehead wisehead added the A-feature feature with good idea label Dec 15, 2022
@wisehead wisehead added the B-storage data type, data storage, insert,update,delete, transactions label Jan 9, 2023
@hustjieke
Copy link
Collaborator

relate to #456, change it to feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-bug Something isn't working A-feature feature with good idea B-storage data type, data storage, insert,update,delete, transactions C-stonedb-5.7 associated with stonedb 5.7 prio: high High priority
Projects
None yet
Development

No branches or pull requests

8 participants