influxdb-rust
influxdb-rust copied to clipboard
Influxdb v2
Is it within the scope of this project to support InfluxDB v2.0.0?
Definetly! We'd have to think how supporting both versions could look and how features need to be adapted.
Hi guys I am working for v2 https://github.com/xoac/influxdb2
I started working on a v2 branch as well and will start pushing once I have something to show 👍
@Empty2k12 Could you say how long you will be doing this? I don't wanna double work I would prefer just create PR.
@xoac Feel free to open a PR for v2 if you have something fully working already. I had just started didn't have a chance to work on it any further due to Corona.
I think I would like to attempt this (within this project). I know the line protocol is identical, and this library did not use UDP, do you have some notes on what actually needs changing? I imagine authentication, since tokens are now used instead of username+password?
I also see the new Serde feature, not sure if the return format of queries is compatible. The query format itself definitely isn't, InfluxQL was deprecated, queries are in Flux language now.
So, any notes? &@xoac
I have defined influx-db line protocol as separate crate: https://github.com/xoac/influxdb-line-protocol and used it with https://github.com/xoac/influxdb2 that at this moment support only writes.
In my opinion if someone is using influxdb v2 shouldn't be forced to go through documentation that are about v1 version and vice-versa. Separate line protocol is natural consequence of above. Rust has awesome dependencies support and splinting things is so easy.
If you want to look how I use inlfuxdb2 with rust I wrote some examples: https://github.com/xoac/influxdb2/tree/master/examples
What I have created incorrectly was PointBuilder this should be definitely refactored
@xoac thank you.
- At the moment I only need writes. However, what I expect a library to be able to do is batch data points while:
- sorting by timestamp
- sorting tags by key as per performance tips
- set per-client (or per-batch) timestamp precision, which should affect:
- query string
precision=[ns,u,ms,s,m,h] - locally sampled time (probably handled by storing
Instant, see below) - serialization precision of
std::time::Instantand types fromchronocrate
- query string
- I am not sure what you meant by "separate line protocol": https://docs.influxdata.com/influxdb/v1.8/write_protocols/line_protocol_reference and https://v2.docs.influxdata.com/v2.0/reference/syntax/line-protocol/ seem identical?
I mean that I needed to create separate crate because influxdb (this project) define line protocol internally and in my opinion it should be separte crate (used by influxdb and influxdb v2 clients). In my opinion ideal scenario would be cargo workspace to have code in one repo but creating holding more crates
Actually v2 has a set of APIs that compatible with v1 (/query and /write), with authorization required. It could be possible to slightly change current client API to make it work with this.
@sunng87 That sounds wonderful. I think it's important to keep compatibility with v1.
I'm definitely interested in just being able to serialize/deserialize v2 requests/responses. Might be worth detaching the client part of the codebase from the raw line protocol one. But I understand that is a very low priority thing. Should we be able to deserialize v2 responses using the logic from this crate?
I have added initial write support here. Meaning it works for me for sending values in a simple scenario. There might be some hidden issues. The branch is based on #92.
Differences I encountered so far are:
dbquery parameter is replaced byorgandbucket.tokenparameter seems to be mandatory (not sure here).- minute and hour timestamp precision are no longer supported
- microseconds precision is now
usinstead ofu
I have added a v2 feature and made it the default. Write query looks like this now:
let _client = Client::new("http://localhost:8086", "ORG", "YOUR_BUCKET", "YOUR API TOKEN");
let write_query = Timestamp::Milliseconds(1629703212874)
.into_query("tst")
.add_field("foo", "bar");
client.query(&write_query).await?;
Given that it's based on #92 I will wait until this is merged before creating a PR.
Looks like #92 has been merged.
@marcelbuesing how far are you on the changes?
Or is there a way to use the library using the v1 api?
Perhaps a dead thread, but wondering if v2 support is on its way or shelved indefinitely.
@reeslabree Afaik there's nobody actively working on this project right now, but I'll be happy to merge a PR if you want to implement this.
@msrd0 All good, it looks like theres an influxdb2 crate out that accomplishes v2 support.
Hi! Any news on support for v2 in this crate?
The compatibility mode of InfluxDB 2.0 is supported since version 0.6 of this crate (I recommend using the latest available version).
The compatibility mode of InfluxDB 2.0 is supported since version 0.6 of this crate (I recommend using the latest available version).
If that is the case, can we close this issue ?