Skip to content
This repository was archived by the owner on Aug 5, 2023. It is now read-only.

Conversation

@slazarov
Copy link

Similar to the epoch in /query

Similar to the epoch in /query
@gusutabopb
Copy link
Owner

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
Copy link
Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants