I wanted to know what is the default secondary sorting applied to the table when we have a custom sorting filter applied by the user? In my case, I have a table that is fed by GQI query, which has default sorting applied. This all works as expected, however when the user applies a custom sorting from the UI, I can see row positions changing every time when table is refreshed, which looks like there is a secondary sorting applied on the table. In this case I would expect the table to be sorted by the user and then default sorting filter applied, which would keep row positions consistent. From my testing it does not seem to be the case, therefore I would like to understand the logic behind this behaviour. Thanks!
Hi Wout,
Thanks for your reply. I have a table that has GQI 'sort by' parameter1 ('event start time' – could be same values for many concurrent events) and 'then sort by' parameter2 ('event name' – rarely have same values) columns, so I get the desired default data view. Every time the table refreshes automatically I get consistent results since double sorting achieves unique row position (almost), ie the rows stay in the same position until sort parameters1 or parameter2 change value for any given row. When the user sorts the table by clicking on one of the table headers (e.g. parameter3), the data is sorted accordingly. However, based on your reply, it looks like initial GQI sorting by paramter1 and parameter2 are dropped and overriden by user sorting parameter3 instead. In this case, if that parameter3 is more generic like 'supplier name' (which is not unique to the row), then after each automatic table refresh, rows keep changing their positions due to the fact that that it cannot asign the same position as there is no unique identifier in the sorting, whereas with secondary sorting it would. In your opinion, would it make sense to keep default GQI sorting, however apply it only after the user sorting? If not, would you have any suggestions how to address this behaviour?
Hi Simonas, thanks for the explanation. With the current table behavior it doesn't make sense to keep the sorting from the query applied while adding the sort from the table since this default sorting isn't displayed on the table headers. This could create confusing situations for the user where the table sorting would look incorrect based on these headers. Note that sorting on consecutive columns in the table itself is also possible and could be a good workaround for your issue. This can be done via the menu that appears when right clicking or by ctrl-clicking on a table header. This is remembered between sessions, but not between users.
Hi Wout,
Thanks for your reply. Funnily enough I found this "hidden" right-click menu and functionality to Sort, Filter and Group just as I posted my comment. Indeed I think it would resolve the issue I was experiencing. Thanks
Hi Simonas,
To give some context about the sorting in GQI:
Applying a sort operator does not guarantee to preserve any previous row order. This is because the sort behavior may depend on the specific data source and we cannot enforce that the sort algorithm used in every case is stable.
Therefore, when a sort operator is applied and later a different sort operator is applied (e.g. by the user) we can optimize the query by ignoring the former sort operator.
Although multi-column sorting is possible (e.g. via the query builder with sort > then sort or Ctrl-clicking table headers), we currently cannot automatically combine 2 independent sort operators into 1 multi-column sort operator because it is not possible in all scenarios and so would introduce inconsistent behavior.
Docs: GQI sorting
Hi Ronald,
Thanks for your reply. I understand that sort operator alone may not guarantee row order, except of few cases such as if sorting was applied on the column that contained GUID, which would mean each row had unique position compared to the others and automatic refresh would not change their order. Another case would be if we had multi-column sorting applied, which would show similar efect depending on how unique the values were within those sorts. In my use case (see my reply to Wout above), current behaviour negatively impacts user experience within live operations team when we have rapid data changes and rows start shifting their order especially at busy times. Would you have any suggestions for a solution? What about a new feature that would allow to "pin" (checkbox ticked) sorting in GQI query, which would then apply it after any user sorting from the UI. If the sorting is 'unpinned' (checkbox unticked), it would behave in the same way as it does now. Something along those lines.
Hi Simonas,
Thank you for your constructive feedback, it is very much appreciated.
If it was feasible, I think on our side we would also prefer the behavior you describe by default. It would be convenient to preserve previous row order in many scenarios.
Meaning: if the query was previously sorted on A, adding a new sorting on B translates to "Sort on B, then on A".
In your use case this would keep the order consistent across refreshes.
Unfortunately, with the current query and operator optimizations we just cannot guarantee this behavior for the reasons I layed out in my reply.
This does not mean we won't try to find a solution to achieve it eventually, but just that it can't be easily resolved by adding a pin option.
As a workaround for now, I would recommend the suggestion from Wout.
Hi Ronald, thanks for your reply. I will try to use the workaround, which might be even better than I hoped for.
Hi Simonas, Can you give an example of rows changing positions? When a user sorts the table by clicking on a header, the existing sort in the query should be ignored. This is similar to adding 2 'sort' nodes in a single query (not 'then sort by').