This uses a purely random v4 UUID instead of a time-based v1 UUID for
the time series UUIDs (which were introduced in
dba9e28fa0 and
2fba2b9721).
As far as I can tell from
b6f6118b65/server/influx.go (L91-L94)
the server uses
b6f6118b65/id/uuid.go (L15)
to generate the `response.uuid` field where clearly a v4 UUID is being
generated. Mixing this with v1 UUIDs in the client code seems odd.
v1 UUID are based on current time and the hardware MAC address of the
machine where they are being generated (although the implementation in
the npm uuid module uses generates a random fake MAC address). As such
they have much more complex semantics than v4 UUIDs which are simply
randomly generated.
Unless there's a specific requirement for the special semantics of v1
UUIDs it is simpler and less error prone to simply go for v4 UUIDs
whenever just a unique identifier is needed.
This uses a purely random v4 UUID instead of a time-based v1 UUID for
the worker message IDs (which were introduced in
1a76a29ed2).
v1 UUID are based on current time and the hardware MAC address of the
machine where they are being generated (although the implementation in
the npm uuid module uses generates a random fake MAC address). As such
they have much more complex semantics than v4 UUIDs which are simply
randomly generated.
Unless there's a specific requirement for the special semantics of v1
UUIDs it is simpler and less error prone to simply go for v4 UUIDs
whenever just a unique identifier is needed.
When a user creates a cell, they can create an InfluxQL query with the
visual query builder. In this case, the query to execute is derived from
the cell's query config. They can also enter a query manually, in which
case the query config should be ignored.
If a user enters a query manually, we attempt to parse that query into a
query config. If we are successful, then it doesn't matter whether we
execute the query that was entered manually, or the query derived from
the query config.
We can't always parse a query back into a query config, but we
nonetheless have always been executing cell queries derived from a query
config. This created the issue witnessed in #5131.
This commit changes that behavior; if a query has been entered manually,
we will always respect it.
Closes#5131
If a user needs to login and there is only one possible location to log
in, we will direct them automatically to that location rather than
rendering a page with a link to that location.
* Match only uppercase TRUE and FALSE as atoms
* Add AND and OR as operators
* Allow variables to begin with capital letters
* Add optional @ to recognize user defined function calls as variables
* Remove multiline comment state add multiline string states
* Add dbrp keyword
* Update changelog
* feat(appReducer): add time zone
* fix(timeZones): local storage
* chore: upgrade to react 16.8.6
* update react types
* feat(status): introduce TimeSelectorToggle component
* feat(ui/status): add time zone to alerts table
* feat(dygraphs): add time zone option
* fix: time typo
This uses a purely random v4 UUID instead of a time-based v1 UUID for
the time series UUIDs (which were introduced in
dba9e28fa0 and
2fba2b9721).
As far as I can tell from
b6f6118b65/server/influx.go (L91-L94)
the server uses
b6f6118b65/id/uuid.go (L15)
to generate the `response.uuid` field where clearly a v4 UUID is being
generated. Mixing this with v1 UUIDs in the client code seems odd.
v1 UUID are based on current time and the hardware MAC address of the
machine where they are being generated (although the implementation in
the npm uuid module uses generates a random fake MAC address). As such
they have much more complex semantics than v4 UUIDs which are simply
randomly generated.
Unless there's a specific requirement for the special semantics of v1
UUIDs it is simpler and less error prone to simply go for v4 UUIDs
whenever just a unique identifier is needed.
This uses a purely random v4 UUID instead of a time-based v1 UUID for
the worker message IDs (which were introduced in
1a76a29ed2).
v1 UUID are based on current time and the hardware MAC address of the
machine where they are being generated (although the implementation in
the npm uuid module uses generates a random fake MAC address). As such
they have much more complex semantics than v4 UUIDs which are simply
randomly generated.
Unless there's a specific requirement for the special semantics of v1
UUIDs it is simpler and less error prone to simply go for v4 UUIDs
whenever just a unique identifier is needed.
When a user creates a cell, they can create an InfluxQL query with the
visual query builder. In this case, the query to execute is derived from
the cell's query config. They can also enter a query manually, in which
case the query config should be ignored.
If a user enters a query manually, we attempt to parse that query into a
query config. If we are successful, then it doesn't matter whether we
execute the query that was entered manually, or the query derived from
the query config.
We can't always parse a query back into a query config, but we
nonetheless have always been executing cell queries derived from a query
config. This created the issue witnessed in #5131.
This commit changes that behavior; if a query has been entered manually,
we will always respect it.
Closes#5131
Michael Desa
Andrew Watkins
Bucky Schwarz
Jacob Marble
Joshua Hoblitt
Alvaro [Andor]
Christoph Tavan
Russ Savage
Christopher Henn
Deniz Kusefoglu