Closed Alexander-Dubrawski closed 3 years ago
Can you show the screenshots of the new UI?
Can you show the screenshots of the new UI?
I could adjust the x-axis as shown in the following example:
Since there is no issue links: was that fix about changing x and y?
Can you name the y-axis "Chunk ID" and skip the "No."? Is that mock data?
Concerning the axis, we could do something that starts at 30 degrees and goes up to 90 once there are more than 20 columns.
Looks good so far. Do you know how hard it would be to integrate the sorting information into the encoding graph? E.g. an arrow in each cell to denote "sorted"?
Since there is no issue links: was that fix about changing x and y?
The fix goes a little bit deeper. In general, the frontend didn't read the data correctly and the backend didn't return the correct data. As a result, the data wasn't plotted correctly.
Can you name the y-axis "Chunk ID" and skip the "No."? Is that mock data?
Yes, I can adjust the naming. Data is not mocked.
Concerning the axis, we could do something that starts at 30 degrees and goes up to 90 once there are more than 20 columns.
The Problem at the moment is that we are using DOM Objects that are kind of fixed and I wasn't able to find out how to manipulate their CSS properties. If we use an angle of 90 degrees the content would overflow and be cut off. But I will have a look again where I can find these properties.
Looks good so far. Do you know how hard it would be to integrate the sorting information into the encoding graph? E.g. an arrow in each cell to denote "sorted"?
I think in theory that should be possible but sadly I have not the knowledge to implement it. I could create an Issue for that.
The fix goes a little bit deeper. In general, the frontend didn't read the data correctly and the backend didn't return the correct data. As a result, the data wasn't plotted correctly
Ok, I see.
Is that mock data? Yes, I can adjust the naming. Data is not mocked.
Then why is just every forth chunk shown? Or do we show them all but have only every forth shown in the in axis? I think we definitely need a thin border in the table.
The Problem at the moment is that we are using DOM Objects that are kind of fixed and I wasn't able to find out how to manipulate their CSS properties. If we use an angle of 90 degrees the content would overflow and be cut off. But I will have a look again where I can find these properties.
That should be straightforward. Nothing important for now, but if you cannot find it easily, please create a ticket. Can you please check out some TPC-H and DS tables on a laptop screen? If 45 degrees works, I am fine with it for now.
Looks good so far. Do you know how hard it would be to integrate the sorting information into the encoding graph? E.g. an arrow in each cell to denote "sorted"?
I think in theory that should be possible but sadly I have not the knowledge to implement it. I could create an Issue for that.
Yes, please create an issue.
Ok, I see.
Is that mock data? Yes, I can adjust the naming. Data is not mocked.
Then why is just every forth chunk shown? Or do we show them all but have only every forth shown in the in axis? I think we definitely need a thin border in the table.
that's a good point. I will look into it.
@Bensk1 @Bouncner here is a screenshot of the implementation, what do you think? An angle of 45 degrees seems to work for the moment.
Angle looks good, but I need to see it with a margin between the cells to make my final verdict.
Angle looks good, but I need to see it with a margin between the cells to make my final verdict.
What exactly do you mean by the margin between the calls? do you mean the margin between the xlabels?
White space between the cells. I cannot find the review comment, but I mentioned it earlier. It shouldn't be a green large rectable, but many green ones. Otherwise nobody understands why the chunk ID show up like "0, 4, 8, 12".
White space between the cells. I cannot find the review comment, but I mentioned it earlier. It shouldn't be a green large rectable, but many green ones. Otherwise nobody understands why the chunk ID show up like "0, 4, 8, 12".
Ok, I will look into it.
White space between the cells
@Bouncner what do you think about the following heatmap:
Fine for me!
Looks superb. BUT I still would like to see the result for TPC-H SF 1 and table lineitem after the compression plugin was activated. Because that's basically what this whole heatmap is for.
Looks superb. BUT I still would like to see the result for TPC-H SF 1 and table lineitem after the compression plugin was activated. Because that's basically what this whole heatmap is for.
That's how it looks on my MacBook (2560 x 1600)
And that's how it looks on my 4k Monitor:
I don't like that we cut off The encoding at the moment (Diction..). And which plugin/settings can I use to get some other encoding into the table?
The compression plugin.
The compression plugin.
How do you like it? Beautiful, isn't it? 🙃
😍
That looks great, thanks!
Just the missing implementation of the aggregation query. As soon as this is implemented and tested, we can merge.
Do you mean the query for the #776 PR? 🙃
This PR fixes the problem with the Segment Configuration.
Before this PR the heatmap looked as followed:
To solve this Issue I adjusted the
monitor/segment_configuration
endpoint in the backend so that it returns the data in a form that is more suitable to build the heatmap. The encoding type and the order type mapped to an integer. The type can be found in amode_mapping
list inside the response to get the real value. For example 0 maps to Dictionary. This way the frontend can use the mapping List for the heat bar in the heatmap and doesn't need to do some extra calculations. As a result, I simplified the corresponding code inside the frontend.Moreover, we can also use the heatmap to show the order mode of the columns.
For that simply press this button:
ToDo:
Chunk ID
and removeNo.
Set flexible trick angle in heatmap(moved to issue)