Support all number types when decoding a point #3828
Conversation
|
cc @jwilder |
| b = append(b, 'i') | ||
| case int64: | ||
| b = append(b, []byte(strconv.FormatInt(t, 10))...) | ||
| b = append(b, 'i') | ||
| case uint: | ||
| b = append(b, []byte(strconv.FormatUint(uint64(t), 10))...) |
There was a problem hiding this comment.
Not sure if there is a good way to handle this but when we parse things back, we use strconv.ParseInt. I believe we could parse back the wrong value if the uint is beyond the max int range. A good test to try would be to have a field type as a uint64 with a value of math.MaxUint64 and format as string and parse back.
There was a problem hiding this comment.
Could we check when we parse back if it starts with a -? If it does, it's ParseInt, if not, it's ParseUint. Would that work?
There was a problem hiding this comment.
I think that would just cause a panic when the shard tries to write: https://github.com/influxdb/influxdb/blob/master/tsdb/shard.go#L509
There was a problem hiding this comment.
Ok, so I think the right fix is to not support uint64. At this point that using the Go client library if you send a uint64 in, that it is going to get converted to a string. If you are using straight line protocol, this won't be an issue, as anything over int64 will fail one of our checks and error out.
/cc @jwilder @beckettsean
|
Since we don't store |
|
👍 On green build. |
Support all number types when decoding a point
Fixes #3824
Also removes the legacy need to append a
.0to float types. This will improve performance and storage.