search

gusutabopb / aioinflux

Asynchronous Python client for InfluxDB
MIT License
159 stars 31 forks source link

Add precision in /write #13

Open slazarov opened 5 years ago

slazarov commented 5 years ago

Similar to the epoch in /query

gusutabopb commented 5 years ago

Thanks for the PR!

What is your use case for this? As things are, the following write attempt:

client = InfluxDBClient(mode='blocking', db='test')
client.write(dict(measurement='foo', time=datetime.now(), fields={'foo': 3.1}), epoch='s')

Would lead to the following error:

InfluxDBWriteError: Error writing data (400 - Bad Request): unable to parse 'foo foo=3.1 1532281714123178000': time outside range -9223372036854775806 - 9223372036854775806

Same applies for anything else that passes something other than an (a properly bounded) integer as the time key. Dataframe writes fail as well.

To keep supporting the current timestamp formats (strings, datetime.datetime, int, etc - see the README for details)) AND this new epoch parameter, some changes would have to be made to aioinflux.serialization.parse_data and all other internal functions it calls, making the implementation not so trivial.

I think in most most use cases it'd be better/easier to do timestamp rounding on user code or during query time (by InfluxDB). In case you really want to go forward with this, can you please elaborate a bit on your use case?

slazarov commented 5 years ago

Hey @gusutabopb,

My specific case is the following: I am getting OHLC data and storing it within InfluxDB. The timestamps are in ms while the precision in InfluxDb is in ns. Hence I was having trouble doing queries related to time e.g now() - 12h. Of course I could multiply the timestamp to get it in the right format but that would waste additional space.

I am noting that I have just begun using InfluxDb so probably there is a workaround, i.e I saw that you can specify precision in /query as well. However, precision is also included in /write as per the official documentation. As a result I reckoned that it could be a useful feature for the library, albeit at the cost of insufficient testing for the general use case on my behalf.