Open qm3ster opened 4 years ago
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.
precision=[ns,u,ms,s,m,h]
Instant
, see below)std::time::Instant
and types from chrono
crateI 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:
db
query parameter is replaced by org
and bucket
.token
parameter seems to be mandatory (not sure here).us
instead of u
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 ?
Is it within the scope of this project to support InfluxDB v2.0.0?