Bug 7052 - Filters in the all layers page return only the information shown in the page
Summary: Filters in the all layers page return only the information shown in the page
Status: RESOLVED FIXED
Alias: None
Product: Toaster
Classification: Build System, Metadata & Runtime
Component: toaster (show other bugs)
Version: 1.7
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.8 M3
Assignee: Michael Wood
QA Contact:
URL:
Whiteboard: all layers page
Depends on:
Blocks:
 
Reported: 2014-12-09 12:50 UTC by Belen Barros Pena
Modified: 2015-02-17 17:12 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: New (Never tested)
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
messed-filters.png (54.87 KB, image/png)
2015-02-02 14:08 UTC, Belen Barros Pena
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Belen Barros Pena 2014-12-09 12:50:21 UTC
Steps to reproduce:

* Create a project with release 'Yocto Project master'
* Import a few layers (3 or 4)
* Go to the all layers page
* Click on the filter button in the 'Layer source' column. In the filter, the information shown refers to the whole information set in the database
* Select the 'Imported layers' source and click apply
* Click again on the filter button in the 'Layer source' column

Result: the information shown in the filter applies only to the subset currently shown on the table

Expected result: filters should always show the information of the whole data set. The only exception to this rule happens when filters are applied to a set of search results. To see the proper behaviour of filters in action, run a build and visit the tasks table.
Comment 1 Belen Barros Pena 2015-02-02 14:08:06 UTC
This seems to happen across Toaster. The attached screenshot (messed-filters.png) is from the project builds page. The 'All builds' counter should show 3 builds, but it shows only 1 (which is the number of builds shown by the filtered table).
Comment 2 Belen Barros Pena 2015-02-02 14:08:30 UTC
Created attachment 2383 [details]
messed-filters.png
Comment 3 Michael Wood 2015-02-10 17:51:11 UTC
The problem is that we're taking the total as the final number of objects returned after filtering them down.

e.g Currently:

compatible (hundreds results) -> filtered / ordered -> (tens results) -> equivalents (fewer results) -> get TOTAL

Possible fix:

compatible (hundreds results) -> equivalents (hundreds results) -> get TOTAL -> filtered / ordered (tens results)

This is what I've done in the all machines page but it's really slow.

The issue is that the equivalents is a really expensive operation which we only want to perform on the smallest dataset possible (which is usually after filters have been applied)

A quick test on the layers page:
Current: 176 queries run
Possible fix: 482 queries run

I'm wondering if we can just not have a number in the "All" part? I know that's not great but is probably a better user experience than the slow down.
Comment 4 Belen Barros Pena 2015-02-11 12:32:29 UTC
Can we cheat? And by this I mean, run the queries to get the counters for the non-all options, then add the results, and display that as the counter for the 'all' option.
Comment 5 Belen Barros Pena 2015-02-13 11:56:04 UTC
After some discussion, we have removed the filters from the all layers page due to performance issues.
Comment 6 Michael Wood 2015-02-17 17:12:37 UTC
poky baa38a14c7d3a71b650b6362641bddbe7aaa3315  (Bitbake rev: ca5124d48d306921ac0f0499762ea5867644b0ef)