Closed Bug 41653 Opened 25 years ago Closed 13 years ago

Restrict queries to at most x bugs.

Categories

(Bugzilla :: Query/Bug List, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 632718

People

(Reporter: CodeMachine, Unassigned)

References

Details

Would be nice to only return x bugs at a time, where you can specify this on the query page. A possibly better alternative would be to limit pages to x bugs and have next/prev buttons.
I like this idea. It would prevent me from accidentally wasting bugzilla's resources when I screw up a query.
I agree this has been necessary for a long time -- pitching in my vote! Right now some large queries return "this was too large for Bugzilla's little brain" -- it'd be much nicer to just show the first 20 or something.
I vote for the default value to be 300. I like scrolling through fairly large bug lists sometimes, but I do want to be caught when I goof and fail to put any meaningful restrictions on my query.
Last time I did a query that returned all of bugzilla, IE crashed my computer :)
See also bug 12282, which would include the ability to just ask bugzilla for the number of bugs matching a query without downloading the list.
Whiteboard: 3.2
moving to real milestones...
Whiteboard: 3.2
Target Milestone: --- → Bugzilla 3.2
Moving to new Bugzilla product ...
Assignee: tara → endico
Component: Bugzilla → Query/Bug List
Product: Webtools → Bugzilla
Version: other → unspecified
*** Bug 137455 has been marked as a duplicate of this bug. ***
Assignee: endico → nobody
QA Contact: mattyt-bugzilla → default-qa
It seems to me that this really ought to be a user pref first, and an extension of the query page second. That would allow users to tell Bugzilla don't show me more than n bugs at once even if there are more available. This would be especially helpful to users with a slower connection. Any WAP interface should probably incorporate this as well.
On the SQL side, that would involve using the "LIMIT,OFFSET" property. I already had b.m.o. running for some minutes without any display back because I did a search too wide by mistake. The worst being that "bad users" (doing large queries) impact "good ones".
(In reply to comment #11) > On the SQL side, that would involve using the "LIMIT,OFFSET" property. > > I already had b.m.o. running for some minutes without any display back because > I did a search too wide by mistake. > > The worst being that "bad users" (doing large queries) impact "good ones". > While I'm not suggesting that this would not help, my experience with SQL queries has generally been that the greatest delay with results is most commonly an issue with getting to the point where results can be returned rather than actually spewing data back to the client. It seems to me that there are times when it's appropriate to limit result sets to a reasonable norm and allow users to override that when there are more results than the norm allows for. Note that I didn't differentiate fishing expeditions versus specific (optimized) queries. Fishing expeditions are usually the ones that just eat up SQL server resources, yet optimized queries can still return large amounts of data. The question is - how to balance the needs of those who are looking for specific result sets versus those who are gone fishin'. :-)
(In reply to comment #12) > While I'm not suggesting that this would not help, my experience with SQL > queries has generally been that the greatest delay with results is most > commonly an issue with getting to the point where results can be returned > rather than actually spewing data back to the client. It seems to me that > there are times when it's appropriate to limit result sets to a reasonable norm > and allow users to override that when there are more results than the norm > allows for. Note that I didn't differentiate fishing expeditions versus > specific (optimized) queries. Fishing expeditions are usually the ones that > just eat up SQL server resources, yet optimized queries can still return large > amounts of data. The question is - how to balance the needs of those who are > looking for specific result sets versus those who are gone fishin'. :-)> So the default setting should be settable by the admin in "user preferences, with a default like "200", and modifiable by users. Actually, this should even only apply to the html "ctype", as the Joe user will not use CSV/other output, don't you think ? The lack of this feature is a bit frustrating, because this is the only major missing "feature" for Bugzilla to me.
And there would be a link to next / previous 200 bugs at the bottom/top of the output, which would change the SQL "OFFSET".
Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2. This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.
Target Milestone: Bugzilla 3.2 → ---
Assignee: nobody → query-and-buglist
Priority: P3 → --
Has been fixed in bug 632718 in Bugzilla 4.2.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.