-
Notifications
You must be signed in to change notification settings - Fork 79
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
Influxdb v2 #56
Comments
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 also see the new Serde feature, not sure if the return format of queries is compatible. 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.
|
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). |
Actually v2 has a set of APIs that compatible with v1 ( |
@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:
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). |
If that is the case, can we close this issue ? |
Is it within the scope of this project to support InfluxDB v2.0.0?
The text was updated successfully, but these errors were encountered: