Influxdb: No way to work with decimal values in InfluxDB

[iwuvjhdva]

Hi,
I need to store prices and money amounts with InfluxDB which seems to be an obvious use case.
Have discovered that there's no proper way to do that.
In case of using string type to store decimal amounts aggregation functions like MAX() SUM() etc don't work on them.
Float numbers don't allow to have strict precision required for currencies.
The only workaround I came up with for the time being is to store the same values both as floats and as strings and use the floats when precision is not vital (like Grafana charts) and the strings when it is.

Proposal: introduce Decimal type, or make functions like SUM() and MAX() to work with string decimals.
Current behavior: No proper way to store and operate on decimals.
Desired behavior: Aggregation works on decimal values, whether by introducing a new type or changing functions behavior or adding the CAST operator.
Use case: storing and querying on currencies or prices or other data where precision is highly important.

[phemmer]

Personally, I solve this issue by using integers. For example instead of using 12.34 to represent $12.34, use 1234. Or if partial cents matter then 123400, etc.

[iwuvjhdva]

Yes, so basically you implement Decimal type manually. Thanks for the input!

On Thu, Oct 19, 2017 at 4:22 PM, Patrick Hemmer [e-mail]
wrote:

Personally, I solve this issue by using integers. For example instead of
using 12.34 to represent $12.34, use 1234. Or if partial cents matter
then 123400, etc.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/influxdata/influxdb/issues/8982#issuecomment-337923414,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALbCkqjEcd2U-60gSNoyQ-bnlgSavRJks5st1sIgaJpZM4P-_JS
.

--
Kind regards,
Konstantin Alexandrov

[rbetts]

A proper decimal with scale and precision would be nice but for supporting monetary use cases, storing at the smallest scale (cents, hundredths, etc.) is a very good solution - and relatively common as a design choice. It can be easier to support correct client side manipulation with this approach, too, as a lot of programming languages don't support first class decimals.

[justinchou]

@rbetts currently i plan to use pandas to store ethereum(a block chain) related data, and the scale is 10^18, the int type will cause unable to parse integer xxx: strconv.ParseInt: parsing \"xxx\": value out of range"} error.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cpick]

This feature request is still valid and would be very helpful.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cpick]

This feature request is still valid and would be very helpful.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had recent activity. Please reopen if this issue is still important to you. Thank you for your contributions.

[Staja]

There are plenty of sensors and telemetry streams where IEEE floats do not provide enough precision, implementing a decimal type on the client end by hacking it onto signed 64-bit ints fixes the precision, is tedious, puts the responsibility on the client and makes writing certain queries problematic.

Is this because there is no native decimal type in Go? Seems like proposals were rejected (https://github.com/golang/go/issues/12127 and https://github.com/golang/go/issues/12332) and their recommendation is to use a separate implementation and, if they start seeing said implementations used, they'll reconsider putting it "somewhere more standard".

[SimonHausdorf]

This feature request is still valid and would be very helpful.