-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove influxdb client precision specification, and unused JSON funcs #4099
Conversation
This looks like a breaking change. Anyone that was depending on precision fields or something other than nanoseconds will either fail to compile or get unexpected results next time they update their client. Should update the changelog too. I'm in favor of removing this code since it adds unnecessary complexity. Not sure what @corylanou @pauldix think though? |
@jwilder I'm actually not sure this is the right solution. Users can write points without specifying a timestamp (but specifying precision), and the DB will truncate time.Now() to the given precision. So to match that behavior, maybe the InfluxDB client should just truncate the given timestamp to the given precision. |
I did not know that without a timestamp the system will truncate to the But actually truncating a given timestamp to the specified precision, with Cameron and I discussed this in depth yesterday. Perhaps there is an On Tuesday, September 15, 2015, Cameron Sparr notifications@github.com
|
It's tricky because if we remove this and say that users of the client need to truncate their own timestamps, then we would also be removing the ability to write data without timestamps at a specific precision |
I did not know about that application of "precison" when we discussed the Hmmm. On Tuesday, September 15, 2015, Cameron Sparr notifications@github.com
|
closing in favor of #4105 |
Truncating to the specified precision is exactly what the database should do. Some people expect that if they write a point at the same second, it will overwrite the previous one, and to ensure that happens truncating at second precision is necessary. The truncation will become even more important with the new storage engine as it will be able to compress timestamps much better when they are lower precision. |
OK @pauldix -- I did not realise that is what we wanted. |
/cc @otoolep @corylanou @jwilder
This became a bit of a rabbit-hole, but basically this is eliminating two things: Setting precision at the influxDB client level, and marshalling and unmarshalling client BatchPoint objects.
There was a bug encountered in Telegraf where if you were writing a set of BatchPoints that had their
Time
field manually set, and then specified aPrecision
other thanns
, InfluxDB would think you were writing very far into the future (see telegraf issue influxdata/telegraf#175)The JSON marshalling part was just a side-effect because there was a lot of code around specifying precision. I spoke with @otoolep about this and we decided it may just be better to delete that code since it's deprecated anyways.