-
Bug Report
-
Resolution: Won't Fix
-
L3 - Default
-
None
-
None
-
None
Scenario:
- Cockpit makes count queries for two purposes: 1) Displaying the exact number of search results in a list view; 2) Displaying the exact number of result pages
- For large datasets and unselective searches, these queries can run for a long time (or event time out) and put significant load on the database server
Proposed improvement:
- No longer display the number of pages; this has very little value for the user and is not worth the expensive queries (e.g. Google search also doesn't give the exact number of pages); some people even consider this an anti-pattern when searching with relational databases (e.g. https://dzone.com/articles/why-most-programmers-get-pagination-wrong)
- Page navigation will then allow you to navigate back and forth between pages, but not to the last page or a specific page anymore.
- For the count that is displayed next to the search result: If runtime data is displayed, show the count immediately (this should cover tasklist). If history data is displayed, show the count only on demand (e.g. have a button to resolve the count).
- Batch creation view: Always show the count when the user has decided to create the batch. In this case, show it in a manner that the user is unlikely to miss (motivation: showing the size of the batch is a tool for our users to notice mistakes before making them)
This is the controller panel for Smart Panels app
[CAM-9642] Count queries issued by Cockpit can be expensive
| Attachment | New: count-use-case2.png [ 27583 ] | |
| Attachment | New: count-use-case1.png [ 27584 ] |
| Description |
Original:
Scenario:
* Cockpit makes count queries for two purposes: 1) Displaying the exact number of search results in a list view; 2) Displaying the exact number of result pages * For large datasets and unselective searches, these queries can run for a long time (or event time out) and put significant load on the database server Proposed improvement: * No longer display the number of pages; this has very little value for the user and is not worth the expensive queries (e.g. Google search also doesn't give the number of pages); some people even consider this an anti-pattern when searching with relational databases * For the count that is displayed next to the search result: Display the exact number of results if the there is only one page of results (i.e. <= 50 results by default); If there are more results, display {{>= 50}};. This should already be sufficient for most users. To get the exact number, we can make the displayed value clickable, so that on click the exact count is retrieved. |
New:
Scenario:
* Cockpit makes count queries for two purposes: 1) Displaying the exact number of search results in a list view; 2) Displaying the exact number of result pages * For large datasets and unselective searches, these queries can run for a long time (or event time out) and put significant load on the database server Proposed improvement: * No longer display the number of pages; this has very little value for the user and is not worth the expensive queries (e.g. Google search also doesn't give the number of pages); some people even consider this an anti-pattern when searching with relational databases (e.g. https://dzone.com/articles/why-most-programmers-get-pagination-wrong) * For the count that is displayed next to the search result: Display the exact number of results if the there is only one page of results (i.e. <= 50 results by default); If there are more results, display {{>= 50}};. This should already be sufficient for most users. To get the exact number, we can make the displayed value clickable, so that on click the exact count is retrieved. |
| Description |
Original:
Scenario:
* Cockpit makes count queries for two purposes: 1) Displaying the exact number of search results in a list view; 2) Displaying the exact number of result pages * For large datasets and unselective searches, these queries can run for a long time (or event time out) and put significant load on the database server Proposed improvement: * No longer display the number of pages; this has very little value for the user and is not worth the expensive queries (e.g. Google search also doesn't give the number of pages); some people even consider this an anti-pattern when searching with relational databases (e.g. https://dzone.com/articles/why-most-programmers-get-pagination-wrong) * For the count that is displayed next to the search result: Display the exact number of results if the there is only one page of results (i.e. <= 50 results by default); If there are more results, display {{>= 50}};. This should already be sufficient for most users. To get the exact number, we can make the displayed value clickable, so that on click the exact count is retrieved. |
New:
Scenario:
* Cockpit makes count queries for two purposes: 1) Displaying the exact number of search results in a list view; 2) Displaying the exact number of result pages * For large datasets and unselective searches, these queries can run for a long time (or event time out) and put significant load on the database server Proposed improvement: * No longer display the number of pages; this has very little value for the user and is not worth the expensive queries (e.g. Google search also doesn't give the exact number of pages); some people even consider this an anti-pattern when searching with relational databases (e.g. https://dzone.com/articles/why-most-programmers-get-pagination-wrong) * For the count that is displayed next to the search result: Display the exact number of results if the there is only one page of results (i.e. <= 50 results by default); If there are more results, display {{>= 50}};. This should already be sufficient for most users. To get the exact number, we can make the displayed value clickable, so that on click the exact count is retrieved. |
| Description |
Original:
Scenario:
* Cockpit makes count queries for two purposes: 1) Displaying the exact number of search results in a list view; 2) Displaying the exact number of result pages * For large datasets and unselective searches, these queries can run for a long time (or event time out) and put significant load on the database server Proposed improvement: * No longer display the number of pages; this has very little value for the user and is not worth the expensive queries (e.g. Google search also doesn't give the exact number of pages); some people even consider this an anti-pattern when searching with relational databases (e.g. https://dzone.com/articles/why-most-programmers-get-pagination-wrong) * For the count that is displayed next to the search result: Display the exact number of results if the there is only one page of results (i.e. <= 50 results by default); If there are more results, display {{>= 50}};. This should already be sufficient for most users. To get the exact number, we can make the displayed value clickable, so that on click the exact count is retrieved. |
New:
Scenario:
* Cockpit makes count queries for two purposes: 1) Displaying the exact number of search results in a list view; 2) Displaying the exact number of result pages * For large datasets and unselective searches, these queries can run for a long time (or event time out) and put significant load on the database server Proposed improvement: * No longer display the number of pages; this has very little value for the user and is not worth the expensive queries (e.g. Google search also doesn't give the exact number of pages); some people even consider this an anti-pattern when searching with relational databases (e.g. https://dzone.com/articles/why-most-programmers-get-pagination-wrong) * Page navigation will then allow you to navigate back and forth between pages, but not to the last page or a specific page anymore. * For the count that is displayed next to the search result: Display the exact number of results if the there is only one page of results (i.e. <= 50 results by default); If there are more results, display {{>= 50}};. This should already be sufficient for most users. To get the exact number, we can make the displayed value clickable, so that on click the exact count is retrieved. |
| Description |
Original:
Scenario:
* Cockpit makes count queries for two purposes: 1) Displaying the exact number of search results in a list view; 2) Displaying the exact number of result pages * For large datasets and unselective searches, these queries can run for a long time (or event time out) and put significant load on the database server Proposed improvement: * No longer display the number of pages; this has very little value for the user and is not worth the expensive queries (e.g. Google search also doesn't give the exact number of pages); some people even consider this an anti-pattern when searching with relational databases (e.g. https://dzone.com/articles/why-most-programmers-get-pagination-wrong) * Page navigation will then allow you to navigate back and forth between pages, but not to the last page or a specific page anymore. * For the count that is displayed next to the search result: Display the exact number of results if the there is only one page of results (i.e. <= 50 results by default); If there are more results, display {{>= 50}};. This should already be sufficient for most users. To get the exact number, we can make the displayed value clickable, so that on click the exact count is retrieved. |
New:
Scenario:
* Cockpit makes count queries for two purposes: 1) Displaying the exact number of search results in a list view; 2) Displaying the exact number of result pages * For large datasets and unselective searches, these queries can run for a long time (or event time out) and put significant load on the database server Proposed improvement: * No longer display the number of pages; this has very little value for the user and is not worth the expensive queries (e.g. Google search also doesn't give the exact number of pages); some people even consider this an anti-pattern when searching with relational databases (e.g. https://dzone.com/articles/why-most-programmers-get-pagination-wrong) * Page navigation will then allow you to navigate back and forth between pages, but not to the last page or a specific page anymore. * For the count that is displayed next to the search result: If runtime data is displayed, show the count immediately (this should cover tasklist). If history data is displayed, show the count only on demand (e.g. have a button to resolve the count). * Batch creation view: Always show the count when the user has decided to create the batch. In this case, show it in a manner that the user is unlikely to miss (motivation: showing the size of the batch is a tool for our users to notice mistakes before making them) |
| Workflow | Original: camunda BPM [ 54466 ] | New: Backup_camunda BPM [ 56641 ] |
| Resolution | New: Won't Fix [ 2 ] | |
| Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
We are closing this ticket as part of our backlog grooming. Reasons: