Update line protocol to require trailing i for field values that are integers

[pauldix]

Many people have reported problems with writing data in and confusion around when a number is a float64 or an int64. Because we take the type of the first written value as that field's type for the measurement, it's causing errors for people later on.

I briefly thought of dropping support for ints (#3479) to make things easier, but it looks like enough people really want them still. So, this will solve the usability problem and give people the ability to still have integers.

After this change in the line protocol, any number in a field will be parsed as a float64, unless that number has a trailing i. Examples:

# here are some float64 values
cpu,host=A value=0
cpu,host=A value=23
cpu,host=A value=23.2

# here are some int64 values
cpu,host=A value=0i
cpu,host=A value=23i

# here is an invalid write that throws an error
cpu,host=A value=23.2i

This will be a breaking change between 0.9.2 and 0.9.3. Hopefully it is small enough that client libraries can be updated with little effort. We had no plan to make breaking changes in the 0.9 line, but this seems the best course of action and it's best to get it out of the way as soon as possible. It's also a very small change.

Apologies for the breakage, but it's our best bet to fix usability and keep those who want integers happy.

[corylanou]

Completed in #3526

[Zolmeister]

In the future (or next release) having an intermediate version which supports both versions would be helpful. e.g. the i is optional, and numbers parsed as usual (unless i present)
Then in the next version enforce non-decimal as floats.

Reason being that we can't upgrade without simultaneous client + db update which increases downtime

[jgeiger]

Is there any way to convert exiting data from int to floats?

[corylanou]

@jgeiger sadly not currently without re-writing all the data. @pauldix any thoughts on a utility to do this in the future?

[pauldix]

@corylanou it would be pretty tricky to create a utility for this, particularly now that we have multiple storage engines that can exist. Not something that can't be done, but we're unlikely to get to it in the next 2 months.

[jportoles]

What about automatically casting numeric values to integers for series that previously held integers? That is to say, make this:

cpu,host=A value=23

Equivalent to this:

cpu,host=A value=23i

If and only if the measurement type is an integer. By doing this 1) you would ensure a smooth non-breaking transition for 0.9.2 users while 2) enforcing float64 by default for new measurements unless values are provided with the 'i' trailing character.

The reason I suggest this is that in our case we tested 0.9.3 today and decided to stay with 0.9.2 for the time being, because figuring out how to properly upgrade our queries in such a way that it works with our existing data is a pain; we can't know the type of an existing measurement in all cases to properly adjust the query since this happened behind the scenes previously.

If InfluxDB casted automatically values for integer measurements, 0.9.2 users could upgrade to 0.9.3 with minimal effort while the new float64 by default rule would still be in effect for everyone.

[Zolmeister]

I agree with @jportoles even if the change is only in effect for 0.9.3 and removed in 0.9.4 for smooth upgrade purposes