[GODRIVER-2244] Golang driver has a rather poor support for Decimal128 Created: 27/Nov/21  Updated: 27/Oct/23  Resolved: 15/Dec/21

Status: Closed
Project: Go Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Unknown
Reporter: Pablo De Napoli Assignee: Benji Rewis (Inactive)
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File shopspringcodec.go    
Issue Links:
Related
is related to GODRIVER-1922 Arithmetic functions with Decimal128 Closed

 Description   

Currently the mogodb driver has support for Decimal128 bson type. However, this type is rather useless as no arithmetic operations are supported on it (only conversions from strings, etc.).

There is a decimal package for go with a rich API at

https://pkg.go.dev/github.com/shopspring/decimal

it would be nice to make compatible with this type or provide a similar API.

Note that a decimal type is very useful for instance in financial applications that require exact representation of the values.

 

 



 Comments   
Comment by PM Bot [ 15/Dec/21 ]

There hasn't been any recent activity on this ticket, so we're resolving it. Thanks for reaching out! Please feel free to comment on this if you're able to provide more information.

Comment by Benji Rewis (Inactive) [ 30/Nov/21 ]

Hello pdenapo@gmail.com, and thanks for your improvement suggestion!

The lack of artithmetic operations on our primitive.Decimal128 type has come up a few times, now. I’ve linked this ticket to a recent request, GODRIVER-1922, that may have some useful context.

To paraphrase from some comments there, we cannot implement arithmetic functions for the Decimal128 type. Our specifications for the Decimal128 type (to which all drivers must adhere) explicitly forbid implementing math operations on the type. No official MongoDB driver has arithmetic methods for their BSON Decimal128 types. Implementing, maintaining, and guaranteeing correctness of IEEE decimal support is far from trivial, and a mistake could be disastrous given the importance of arbitrary-precision-decimal-floating-point-number arithmetic (especially in, as you mentioned, financial applications).

We do understand that converting between primitive.Decimal128 and other popular decimal libraries (like shopspring) can add undesired overhead to perform arithmetic functions. The main pain point there seems to be having to check errors for conversions to and from primitive.Decimal128.

We can suggest an alternative of registering a custom BSON codec for your preferred decimal type that converts to and from primitive.Decimal128. Doing so would mean that conversion errors only appear in Marshaling and Unmarshaling, and you could insert/query with your preferred decimal type rather than primitive.Decimal128. That way, from your application’s point of view, you’d never even touch primitive.Decimal128. Decimal values would only be stored in your collections as primitive.Decimal128. I’ve attached an example of registering a custom codec for shopspring.Decimal.

shopspringcodec.go

Does that solution seem like it might help in your case? If not, feel free to elaborate on your use-case, and I may be able to suggest other paths forward.

Generated at Thu Feb 08 08:38:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.