Translate the measurement and field tag key names to their non-storage
names and add the `_start` and `_stop` tag keys to the output since
they aren't real tags, but ones that are added by range.
StringArrayEncodeAll will panic if the total length of strings
contained in the src slice is > 0xffffffff. This change adds a unit
test to replicate the issue and an associated fix to return an error.
This also raises an issue that compactions will be unable to make
progress under the following condition:
* multiple string blocks are to be merged to a single block and
* the total length of all strings exceeds the maximum block size that
snappy will encode (0xffffffff)
The observable effect of this is errors in the logs indicating a
compaction failure.
Fixes#13687
The encoding/json docs explain that you need to provide a MarshalText
method to encode integer types as map keys, otherwise they will be
formatted as a string version of the decimal number.
Providing MarshalText and UnmarshalText also uses those methods as a
fallback for MarshalJSON and UnmarshalJSON, so we no longer need
explicit versions of those latter methods.
Apparently Sources were using IDs as map keys and were providing the
,string attribute on the JSON tag on the struct. This was not correct so
that attribute has been removed. Existing sources will no longer be
readable as a result of this change.
Fixes#13277.
Currently, slight changes in the form of a Flux metaquery can have
drastic performance implications. To solve this issue, the Flux language
provides helper metaquery functions such as `v1.tagKeys` and
`v1.tagValues` which are guaranteed to be as fast as possible.
In #12791, we switched away from using the `v1.tagKeys` and
`v1.tagValues` functions in the query builder to their underlying Flux
implementations in order to implement a UI feature. While the new
metaqueries used in the query builder were still optimized at the time,
the Flux language has since changed and this is no longer the case.
In addition, the metaqueries in the UI no longer hit the same code-path
in Flux which has exposed a logic bug in the queries. So when executed,
the metaqueries return the following error:
schema collision detected: column ""_value"" is both of type float and int
This PR updates the metaqueries used in the query builder to their
[currently optimized form][0]. The long term solution is to address
[this][1] issue and then switch back to using the safer `v1.tagKeys` and
`v1.tagValues` functions directly.
[0]: https://github.com/influxdata/flux/blob/master/stdlib/influxdata/influxdb/v1/v1.flux
[1]: https://github.com/influxdata/flux/issues/1071
Closes https://github.com/influxdata/influxdb/issues/13660
When printing out a stacktrace with a logged error message, it is better
to set the `Stack` property on the entry than to include it as a string
within the context fields. It is also better than using `zap.Stack()`
too.
This is because certain encoders will perform a pretty print of the
stacktrace. The default zap-logfmt will read this property and include
it as a field so this code is identical when using that encoder, but the
console encoder, which is commonly used in local development because it
is automatically used with a TTY available, will print out a newline and
pretty print the stacktrace if it is included on the entry itself.
The RPC call should translate `_measurement` and `_field` to their
proper shortened byte strings when requesting the tag values.
This also fixes the planner rewrites to return the root node even when
no rewrite happened as this is required by the planner.
Deniz Kusefoglu
Stuart Carnie
Lyon Hill
Alirie Gray
Russ Savage
Andrew Watkins
Jeff Wendling
Jonathan A. Sternberg
Gunnar
Jeff Wendling
Jade McGough
Leo Di Donato
Delmer
Mark Rushakoff
Palakp41
Kelvin Wang
Christopher Henn
kelwang
zhulongcheng