fabric
fabric copied to clipboard
BigDecimal data type storage issue
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, 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.
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 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.
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 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
Thanks for your response @davidkel. We had a thought of using String datatype but it was business requirement to use Big Decimal.
@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 ?