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?