Influxdb v2

[qm3ster]

Is it within the scope of this project to support InfluxDB v2.0.0?

[Empty2k12]

Definetly! We'd have to think how supporting both versions could look and how features need to be adapted.

[xoac]

Hi guys I am working for v2 https://github.com/xoac/influxdb2

[Empty2k12]

I started working on a v2 branch as well and will start pushing once I have something to show 👍

[xoac]

@Empty2k12 Could you say how long you will be doing this? I don't wanna double work I would prefer just create PR.

[Empty2k12]

@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.

[qm3ster]

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

[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

[qm3ster]

@xoac thank you.

1. At the moment I only need writes. However, what I expect a library to be able to do is batch data points while:
   1. sorting by timestamp
   2. sorting tags by key as per performance tips
   3. set per-client (or per-batch) timestamp precision, which should affect:
      1. query string precision=[ns,u,ms,s,m,h]
      2. locally sampled time (probably handled by storing Instant, see below)
      3. serialization precision of std::time::Instant and types from chrono crate
2. 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?

[xoac]

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

[sunng87]

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.

[Empty2k12]

@sunng87 That sounds wonderful. I think it's important to keep compatibility with v1.

[doivosevic]

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?

[marcelbuesing]

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).
• minute and hour timestamp precision are no longer supported
• microseconds precision is now 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.

[iicurtis]

Looks like #92 has been merged.

[johansmitsnl]

@marcelbuesing how far are you on the changes?

Or is there a way to use the library using the v1 api?

[reeslabree]

Perhaps a dead thread, but wondering if v2 support is on its way or shelved indefinitely.

[msrd0]

@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.

[reeslabree]

@msrd0 All good, it looks like theres an influxdb2 crate out that accomplishes v2 support.

[LeoBorai]

Hi! Any news on support for v2 in this crate?

[msrd0]

The compatibility mode of InfluxDB 2.0 is supported since version 0.6 of this crate (I recommend using the latest available version).

[patrickelectric]

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 ?

[tolik518]

The documentation is really lacking, but v2 is available for some time, see: https://github.com/influxdb-rs/influxdb-rust/blob/main/influxdb/tests/integration_tests_v2.rs

So the issue can be closed.

[Empty2k12]

@tolik518 I think this is using a the V2 compat mode to v1. Ideally for proper v2 support, we'd be speaking v2 with v2 directly. However, I am unsure how big the return of invest of implementing something like that really is.

[tolik518]

@Empty2k12 rust is growing and this library is the first one that shows up on Google. So I guess it either gets implemented over here, or another library will implement it.

I don't know enough enough about InfluxDb to tell you if it's really worth it though

[msrd0]

So I guess it either gets implemented over here, or another library will implement it.

Starting influxdb 3.0 this library might not even be necessary anymore: https://github.com/influxdata/influxdb/tree/main/influxdb3_client

And so far nobody has implemented it for this library, and a crates.io search returns influbdb2 so I guess another library already beat us to it. (This was also already mentioned in this thread multiple times)