feature(graphs): filter data points by date filters #491
Conversation
|
It's deployed to staging. |
| parameters.append(end_date) | ||
|
|
||
| if start_date or end_date: | ||
| raw_query += " ALLOW FILTERING" |
There was a problem hiding this comment.
do we have some estimation of the performance of those queries ? before/after ?
There was a problem hiding this comment.
No, but in general should be faster as there will be less data sent to the backend.
Possibly this whole table could be improved by making SUT_TIMESTAMP a static field - as we don't support different SUT versions for one test run. I'd consider doing this in separate PR. WDYT?
the layout looks good to me, |
maybe it's time to do a session with a designer, about the UI of those ? |
In order to narrow down graphs range, date filters were added (by start and end date) with ability to quickly switch between 1,3 and 6 recent months. Last 3 months filter is on by default. closes: scylladb#474
soyacz
force-pushed
the
add-filter-data-points-in-graph-by-date
branch
from
5b59348
to
cf0309d
Compare
I can look into the UI/UX after this PR, we've discussed some changes in #489. |
| if not test_id: | ||
| raise Exception("No testId provided") | ||
|
|
||
| start_date = datetime.fromisoformat(start_date_str).astimezone(timezone.utc) if start_date_str else None |
There was a problem hiding this comment.
What does the input string here look like? My concern is potential shift of the requested data +/- offset from UTC if input string doesn't have Z at the end or timezone specified.
There was a problem hiding this comment.
input string is just the date e.g. 2024-10-30
Yes, I tried improving UI/UX but I'd rather do it in separate PR to discuss it there out of this context. |
In order to narrow down graphs range, date filters were added (by start and end date) with ability to quickly switch between 1,3 and 6 recent months. Last 3 months filter is on by default.
closes: #474