You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suspect everything I'm showing here is effectively working as designed, but looking at it through the eyes of a community user that I was helping out, it may be worthy of closer study. I'm working with the JSON file inside test data apt29_evals_day1_manual.zip.
As shown in the attached video, the test data has a timestamp field called EventTime that starts out as a string, so I apply EventTime:=time(EventTime) in the main query window to turn it into a time type. I then I attempt to set it as the Time Field for my stacked bar chart, but the chart does not render. If I set the Time Field to time(EventType) it does work, but I'm expecting most users may not figure that out on their own because it feels redundant with what I just did in the main query window.
Repro.mp4
Looking at the fine print in #2785 and sniffing in Wireshark, I'm pretty sure I see what's going on: The "max and min" query to determine the X axis range is executed using the Time Field, but that query is run directly against the base pool, e.g.:
from 0x11b1e481b721cf05cd09d06fca984f601cd88698 | min(EventTime), max(EventTime)
...not against the result of the query executed in the main window, which would be:
from 0x11b1e481b721cf05cd09d06fca984f601cd88698 | EventTime:=time(EventTime) | min(EventTime), max(EventTime)
Since the EventTime field in the base pool is of string type, I suspect that when the min/max query doesn't return time values, the app assumes it can't render the bar chart since it can't construct a valid time-based X axis. And my setting the Time Field to time(EventType) works around that because now the min/max query against the base pool looks like:
from 0x11b1e481b721cf05cd09d06fca984f601cd88698 | min(time(EventTime)), max(time(EventTime))
...so it gets its time values, and therefore it can proceed.
No doubt once #2834 merges the guidance to all users will be to do shaping like EventTime:=time(EventTime) before the data is loaded into the pool and none of this will happen. However, there may still be times when users realize post-load that they want to work with some alternate time field that wasn't pre-shaped, so this problem could still come up.
My question is this: Should the min/max query be done on the data result from the query in the main window, not against the base pool? I suspect the reason it's being done as it is today is so the endpoints of the X axis aren't changing constantly as the query trims the number of values returned. However, since the bars drawn in the bar chart are all drawn based on the result of the query in the main window, maybe it would be appropriate to do the min/max on the same?
The text was updated successfully, but these errors were encountered:
Repro is with Zui commit cee56fa.
I suspect everything I'm showing here is effectively working as designed, but looking at it through the eyes of a community user that I was helping out, it may be worthy of closer study. I'm working with the JSON file inside test data apt29_evals_day1_manual.zip.
As shown in the attached video, the test data has a timestamp field called
EventTime
that starts out as a string, so I applyEventTime:=time(EventTime)
in the main query window to turn it into atime
type. I then I attempt to set it as the Time Field for my stacked bar chart, but the chart does not render. If I set the Time Field totime(EventType)
it does work, but I'm expecting most users may not figure that out on their own because it feels redundant with what I just did in the main query window.Repro.mp4
Looking at the fine print in #2785 and sniffing in Wireshark, I'm pretty sure I see what's going on: The "max and min" query to determine the X axis range is executed using the Time Field, but that query is run directly against the base pool, e.g.:
...not against the result of the query executed in the main window, which would be:
Since the
EventTime
field in the base pool is ofstring
type, I suspect that when the min/max query doesn't returntime
values, the app assumes it can't render the bar chart since it can't construct a validtime
-based X axis. And my setting the Time Field totime(EventType)
works around that because now the min/max query against the base pool looks like:...so it gets its
time
values, and therefore it can proceed.No doubt once #2834 merges the guidance to all users will be to do shaping like
EventTime:=time(EventTime)
before the data is loaded into the pool and none of this will happen. However, there may still be times when users realize post-load that they want to work with some alternate time field that wasn't pre-shaped, so this problem could still come up.My question is this: Should the min/max query be done on the data result from the query in the main window, not against the base pool? I suspect the reason it's being done as it is today is so the endpoints of the X axis aren't changing constantly as the query trims the number of values returned. However, since the bars drawn in the bar chart are all drawn based on the result of the query in the main window, maybe it would be appropriate to do the min/max on the same?
The text was updated successfully, but these errors were encountered: