Closed Bug 1016920 Opened 10 years ago Closed 10 years ago

Filtering cases into a new suite is not functioning

Categories

(Mozilla QA Graveyard :: MozTrap, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 1023439

People

(Reporter: ericcc, Unassigned)

Details

Attachments

(3 files)

### STR
1. Search for tag "edward.2.0" in Manage -> Cases.
2. 77 results shown.
3. Manage -> Suites 
4. Filtering "edward.2.0" or anything in cases.
5. <ISSUE> Unrelated cases shown, and it doesn't work if we need to put 2nd word to search, maybe it is due to timeout, and returns whatever it has at that moment. Because it returns the same thing no matter what keyword is provided.
6. Select all cases with "edward.2.0" to the new suite.
7. only 32 cases found in that suite.
Peterbe,

After you land some of the performance improvements, can you have a look at this issue as well?
Sure can. Rushing to finish Q goals at the moment followed by a slight backlog pushed back due to mentioned goals.
Any update on this? Currently the filtering is pretty bad in MozTrap and it is making it very difficult to create new Test Suites and add test cases to them.
Hi Marcia - Peter and I just had a meeting about this.  We can reproduce the problem and have a solution in mind.  

Peter is going to work on this to get the filtering working.  In addition, we're going to change that page so that it doesn't load EVERY available test case when you first load it.  In fact, it won't load any available cases until you click the new "Load Cases" button.  This will allow you to add your filter criteria before hand.  This will save you from waiting through an unfiltered load every time you create a new suite.
Mainly some note-to-selfs (and camd):
The mysql query to fetch all them cases for "Firefox OS" takes 1-2 seconds, serializing the objects to JSON takes 1 second but the whole request takes about ~50 seconds on my fast laptop. 
There is a very "angry" issue on tastypie [0] which would make it roughly half the 50 seconds but that's still crazy-slow. 
We could probably move this query away out of tastypie screwing it up and writing our own view function that just selects the objects as pure dicts and serializes that. We'll still have a 1Mb JSON blob at worst but at least we should be able to generate it in about 2-3 seconds. 


[0] https://github.com/toastdriven/django-tastypie/issues/720#issuecomment-46071701
This was fixed by peterbe.  Pushed to prod
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Bumping to verified duplicate
Status: RESOLVED → VERIFIED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: