With the recent changes in the server, and the move to using CustomQuery as much as possible comes also a new infrastructure for calculating queries on the server. This infrastructure will always result a QueryResult object in response to a query that will be sent to it.
Right now we cannot interpret QueryResult objects in the app, but it should be our goal to moving towards displaying these properly. This can lead to a partial refactoring or redesign of how charts and insights are displayed – let your heart be your guide.
A QueryResult object has 3 sub-objects. All of these might be special cases in most ways of displaying them.
TimeSeriesQueryResult
TopNQueryResult
GroupByQueryResult
The following is an overview over the possible display types we should be able to display.
Debug Display: Show Raw JSON
[ ] Debug: Create a way to just show the raw QueryResult as JSON text
This will help us figure out the infrastructure of how the new QueryResult works, especially together with task-based queries. It will also help us get up and running and rule out other errors. If something doesn't work, we can check the raw JSON view.
Table Display 🔢
The current raw display type tries to be pretty smart in figuring out what information to display: It can become a table, a single number, or a single number that auto-compares to the previous number. However, even as the table, it can always only display Integers right now, and only one or two columns. It needs to be replaced by a version that is even more flexible.
We should make this more explicit, so we're splitting it up into a 'single number" display, and a 'table' display. The table should always try to represent the data as accurately as is possible in a two-dimensional table. This means numbers should don't be abbreviated into e.g. "12K" instead of "12,293", and all lines and columns of the column should be accessible, even if this leads to scrolling.
[ ] Show a TimeSeriesQueryResult as a table
[ ] Show TopNQueryResult as a table
[ ] Show a GroupByQueryResult as a table
️⃣ Single Number Display
The single number should always display the first row of the query result only. If there is more than one row, it should show the second row smaller, and compare the first row to the second row if possible. If there are more than two rows, all subsequent rows are ignored.
The single number display should very much look like a widget, with fonts, sizes and margins inspired by e.g. the calendar widget.
[ ] Show a GroupByQueryResult as a single number if it only has one entry
[ ] Show a TopNQueryResult as a single number if it only has one entry
[ ] Show a TimeSeriesQueryResult as a single number if it only has one entry
📊 Bar Chart
Bar Charts work just as before, so it might be enough to create some glue code between the various QueryResult flavors and the existing implementation. The current bar chart implementation does not support stacked bars, and moving to stacked bars is not part of this ticket – it's okay to ignore part of the data if that data would result in a stacked bar chart.
[ ] Show a TimeSeriesQueryResult as a bar chart
[ ] Show TopNQueryResult as a bar chart
[ ] Show a GroupByQueryResult as a bar chart
Note that bar charts make mostly only sense for groupBy and time series results, but let's implement them for topN results anyways. It's not a lot of additional work, and it might be helpful to see, e.g. a representation of how the values are distributed in a topN result.
📈 Line Chart
Same situation as with bar charts: multiple lines are not part of this ticket, just ignore additional data sets. Also, they should be implemented for all current results types.
[ ] Show a TimeSeriesQueryResult as a line chart
[ ] Show TopNQueryResult as a line chart
[ ] Show a GroupByQueryResult as a line chart
🍩 Donut Chart
Donut Charts could in theory display multiple data sets by having multiple rings, but we're going to ignore that for now. So same idea: Just pick the first dataset and update the donut charts in a way that can display it.
With the recent changes in the server, and the move to using
CustomQuery
as much as possible comes also a new infrastructure for calculating queries on the server. This infrastructure will always result aQueryResult
object in response to a query that will be sent to it.Right now we cannot interpret
QueryResult
objects in the app, but it should be our goal to moving towards displaying these properly. This can lead to a partial refactoring or redesign of how charts and insights are displayed – let your heart be your guide.A
QueryResult
object has 3 sub-objects. All of these might be special cases in most ways of displaying them.TimeSeriesQueryResult
TopNQueryResult
GroupByQueryResult
The following is an overview over the possible display types we should be able to display.
Debug Display: Show Raw JSON
This will help us figure out the infrastructure of how the new QueryResult works, especially together with task-based queries. It will also help us get up and running and rule out other errors. If something doesn't work, we can check the raw JSON view.
Table Display 🔢
The current raw display type tries to be pretty smart in figuring out what information to display: It can become a table, a single number, or a single number that auto-compares to the previous number. However, even as the table, it can always only display Integers right now, and only one or two columns. It needs to be replaced by a version that is even more flexible.
We should make this more explicit, so we're splitting it up into a 'single number" display, and a 'table' display. The table should always try to represent the data as accurately as is possible in a two-dimensional table. This means numbers should don't be abbreviated into e.g. "12K" instead of "12,293", and all lines and columns of the column should be accessible, even if this leads to scrolling.
️⃣ Single Number Display
The single number should always display the first row of the query result only. If there is more than one row, it should show the second row smaller, and compare the first row to the second row if possible. If there are more than two rows, all subsequent rows are ignored.
The single number display should very much look like a widget, with fonts, sizes and margins inspired by e.g. the calendar widget.
📊 Bar Chart
Bar Charts work just as before, so it might be enough to create some glue code between the various QueryResult flavors and the existing implementation. The current bar chart implementation does not support stacked bars, and moving to stacked bars is not part of this ticket – it's okay to ignore part of the data if that data would result in a stacked bar chart.
Note that bar charts make mostly only sense for groupBy and time series results, but let's implement them for topN results anyways. It's not a lot of additional work, and it might be helpful to see, e.g. a representation of how the values are distributed in a topN result.
📈 Line Chart
Same situation as with bar charts: multiple lines are not part of this ticket, just ignore additional data sets. Also, they should be implemented for all current results types.
🍩 Donut Chart
Donut Charts could in theory display multiple data sets by having multiple rings, but we're going to ignore that for now. So same idea: Just pick the first dataset and update the donut charts in a way that can display it.