Closed
Bug 41653
Opened 25 years ago
Closed 13 years ago
Restrict queries to at most x bugs.
Categories
(Bugzilla :: Query/Bug List, enhancement)
Bugzilla
Query/Bug List
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.
Comment 1•25 years ago
|
||
I like this idea. It would prevent me from accidentally wasting bugzilla's
resources when I screw up a query.
Comment 2•25 years ago
|
||
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.
Comment 3•25 years ago
|
||
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.
Comment 4•24 years ago
|
||
Last time I did a query that returned all of bugzilla, IE crashed my computer :)
Comment 5•24 years ago
|
||
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.
Reporter | ||
Updated•24 years ago
|
Whiteboard: 3.2
Comment 6•24 years ago
|
||
moving to real milestones...
Whiteboard: 3.2
Target Milestone: --- → Bugzilla 3.2
Reporter | ||
Comment 7•23 years ago
|
||
Moving to new Bugzilla product ...
Assignee: tara → endico
Component: Bugzilla → Query/Bug List
Product: Webtools → Bugzilla
Version: other → unspecified
Comment 8•21 years ago
|
||
*** Bug 137455 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Assignee: endico → nobody
Updated•19 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Comment 9•19 years ago
|
||
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.
Comment 11•18 years ago
|
||
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".
Comment 12•18 years ago
|
||
(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'. :-)
Comment 13•18 years ago
|
||
(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.
Comment 14•18 years ago
|
||
And there would be a link to next / previous 200 bugs at the bottom/top of the output, which would change the SQL "OFFSET".
Comment 15•17 years ago
|
||
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 → ---
Updated•16 years ago
|
Assignee: nobody → query-and-buglist
Priority: P3 → --
![]() |
||
Comment 16•13 years ago
|
||
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.
Description
•