fabric icon indicating copy to clipboard operation
fabric copied to clipboard

BigDecimal data type storage issue

Open shubham-umate opened this issue 3 years ago • 7 comments

BigDecimal value getting wrongly truncated beyond 13-15 digits while writing to ledger. Java is being used for SDK and CC. CouchDB as a database.

shubham-umate avatar Apr 18 '22 05:04 shubham-umate

@shubham-umate, can you please share some more details like what is the actual value you are using (example of your chain code) and what is the truncated value it stores? It may be something to do with CouchDB and not with fabric code.

ketulsha avatar Apr 18 '22 12:04 ketulsha

Thanks for your response @ketulsha. Ex, For Big Decimal datatype, 123456789012345.798 is getting stored as 123456789012345.8 and 9999999999999999.12345 as 10000000000000000.

shubham-umate avatar Apr 20 '22 12:04 shubham-umate

@shubham-umate I think you need to review how you serialize and deserialize your BigDecimal objects. For example if you serialize a big decimal object to JSON eg

{"val": 123456789012345.798}

then val in the above is considered a number and if I run some simple code in node then you see the truncation occurs

> const x = '{"val": 123456789012345.798}';
undefined
> const y = JSON.parse(x);
undefined
> console.log(y)
{ val: 123456789012345.8 }

I think you need to change how you are serializing/deserializing you BigDecimal objects to cater for this.

davidkel avatar Apr 25 '22 16:04 davidkel

Thanks @davidkel. FYI : We are using stub.putStringState(assetID, assetJson) method in Java chaincode. We logged value before writing it to ledger to check whether serializing/deserializing is causing this issue, but No truncation was happening there. Post putStringState() method value is getting truncated and saved in ledger.

shubham-umate avatar Apr 27 '22 17:04 shubham-umate

@shubham-umate I would suggest you visit how you create assetJSON. If the JSON you create takes the big decimal value and tries to represent it as a number as per my example above then that could be the issue. I would suggest you try creating a different serialized representation of the big decimal in your JSON. I'm not familiar with Java but maybe you could serialize it to a string rather than a number, eg {"val":"123456789012345.798"} and when you deserialize you can create a BigDecimal from that string

davidkel avatar Apr 27 '22 22:04 davidkel

Thanks for your response @davidkel. We had a thought of using String datatype but it was business requirement to use Big Decimal.

shubham-umate avatar Apr 28 '22 12:04 shubham-umate

@shubham-umate I'm not saying to not use Big Decimal, just how that get's serialized to JSON and deserialized. If it's being serialized as a JSON number then that could be the problem so serialize it as a JSON string instead ?

davidkel avatar Apr 28 '22 12:04 davidkel