-
Notifications
You must be signed in to change notification settings - Fork 17
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
Support for InfluxDB 2.x #92
Comments
Dear Aurélio, thank you for writing in and for the kind words 1. Well, it would be sweet if Kotori would have support for InfluxDB 2.x, and maybe also other databases as storage backends. While we might come back to this feature request in a few months or so, we would like to outline the places 234, where some adjustments would need to be applied, in case anyone would like to start working on implementing this feature. We can imagine implementing and shipping the feature in two subsequent steps. We think implementing the first step would be pretty valuable already, at least for some users.
What do you think about it? Would you need both parts to be implemented, or would step one be favorable to you already? With kind regards, Footnotes
|
Dear Andreas, Thank you for your quick response. 1.Receive/ingest data payloads and write them to InfluxDB 2.x buckets. Let me know if in addition to the points you mentioned, there would also be an update on the project https://github.com/daq-tools/pyinfluxql => Flux With kind regards, |
Hi again,
You are absolutely right. 1 and 2 are two other spots which would need to be adjusted. Thank you for mentioning that!
I am not sure about it. Maybe the semantics don't fit well together, as InfluxDB 2.x has different addressing (database vs. bucket) and different query language structure (InfluxQL vs. Flux). Maybe it would become a whole mess when trying to squeeze all into the same package. We would have to evaluate this detail when spending some more thoughts on this topic. With kind regards, Footnotes |
Hi again, We could update the "influxdb-python client library" module by the "influxdb-client-python" module In the link https://github.com/influxdata/influxdb-client-python We check a note: Note: Use this client library (influxdb-client-python) with InfluxDB 2.x and InfluxDB 1.8+. The fact that kotori is using influxdb 1.8 wouldn't have some facilities? With kind regards, |
Hi Aurelius, thank you for sharing this detail. Yes, using that client library was planned for supporting InfluxDB 2.x. The section at [1] has some more details about compatibility with InfluxDB 1.8, where it is stated that it will also use the new API based on the "buckets" addressing scheme. Currently, Kotori supports InfluxDB 1.6 - 1.8, through the previous "database/collection" addressing scheme. I am not objecting against dropping support for the InfluxDB 1.x series, but I would favor to have them both supported in parallel. Actually, we are still running InfluxDB 1.7 on the majority of our production servers. With kind regards, [1] https://github.com/influxdata/influxdb-client-python#influxdb-1-8-api-compatibility |
Dear Andreas, This project can serve as an inspiration (Coded in JS): https://github.com/ioBroker/ioBroker.influxdb
The following observation caught my attention:
With kind regards, |
Hi again, I just want to share some additional thoughts on this topic. I believe, when starting to work on this feature/improvement, we should aim for converging all that InfluxDB-specific code scattered throughout the code base into a subsystem with a more well-defined interface. Based on that interface, data source adapters for other databases could be implemented more easily. For example, I would like to add support for CrateDB 1 or other PostgreSQL-compatible databases in the future as well. With kind regards, Footnotes |
Kotori is a great tool. Is an update that supports InfluxDB 2.x in your future plans?
The text was updated successfully, but these errors were encountered: