-
Notifications
You must be signed in to change notification settings - Fork 115
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
Query into Point structs #380
Comments
This gives me something that resembles a Point struct. |
Hi, When sending data to InfluxDB, it needs to be in line protocol format. The point helper class essentially is a wrapper around that format. When querying data in InfluxDB v2, flux is used to query and return data in a format that is more easily used for additional querying, filtering, and parsing. Having a function that would take the flux tables that are returned and converting that data into line protocol might be possible, assuming that all the field and tag data is present. We would accept a PR that provides this functionality, but it is not something we would prioritize as part of our own future development. Thanks |
Proposal:
I'd like to have symmetry between writes and reads. When writing data into Infludb one would use a Point struct, with strict Tags, Fields, Measurement and Time values. When querying the data I want to see the returned results in this same format.
Current behavior:
The Point object when writing data is clear, and follows the basic concepts of Tags and Fields. When querying data the result is a pointer that contains a messy combination of tables and columns. Filtering these columns into Tags and Fields are tricky.
Desired behavior:
A query should ideally return the same format struct as what is written to the database. In other words I should be able to take a result and write it directly back to the database, without any data being lost. Updating a field would then be a write, update of the field value, and then a write.
Alternatives considered:
Describe other solutions or features you considered.
Use case:
Why is this important (helps with prioritizing requests)?
The text was updated successfully, but these errors were encountered: