[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: |
|
||||||||
| Issue Links: |
|
||||||||
| 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, 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. 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. |