Closed
Bug 729255
Opened 13 years ago
Closed 13 years ago
Optionally page result sets returned from mediawiki-bugzilla
Categories
(Websites :: wiki.mozilla.org, defect)
Websites
wiki.mozilla.org
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: lmandel, Unassigned)
References
Details
(Whiteboard: [mediawiki-bugzilla])
The mediawiki-bugzilla integration provides the ability to embed a bugzilla query in a mediawiki page. If the result set for a query is sufficiently large it poses two problems:
1. It may consume more memory than has been allocated to mediawiki causing a blank page to be displayed. The user then needs to know how to craft the edit URL manually in order to recover.
2. It may result in a very large page with a huge bug list.
I would like to see an optional parameter for the query that allows for paging the results.
<bugzilla pagesize="20">
pagesize should be a non negative integer. If we think there is a range that makes sense we can set the valid range (no more than 500, 1000?). I would suggest that this be set to a reasonable size, say 20, by default.
If the bugzilla REST API doesn't provide this capability it can be baked into this extension by only displaying results for the page size.
Reporter | ||
Updated•13 years ago
|
Whiteboard: [mediawiki-bugzilla]
Comment 1•13 years ago
|
||
This bug cannot be fixed, due to the fact that the Bugzilla API does not permit pagination. While displaying only a subset of results is possible (and is done with the javascript table), the performance impact of a huge result set from Bugzilla's API renders the suggested solution in the description useless from a practical standpoint.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 2•13 years ago
|
||
First, I agree that this is not necessary once the JS table is fixed.
There is benefit in this request besides requesting less data from Bugzilla. Large result sets cause wiki pages to be unreadable. It is better to display a subset of the results so that the results can be consumed by humans. (Again, JS table will fix this issue.)
FWIW, I do think we could have implemented something useful using the result set stored in the cache.
Leave as won't fix. Goal is to fix existing JS table.
Comment 3•13 years ago
|
||
There are a lot of things we can do with the result set once we have it, but the bug is pretty much not worth fixing without being able to page the data coming back from Bugzilla. The bug is caused due to the data coming back from Bugzilla being too large or taking too long. Still, we could file a feature request against Bugzilla to add this feature to the API.
Reporter | ||
Comment 4•13 years ago
|
||
As stated in bug 735948 comment 1, The Bugzilla REST API is in maintenance mode. I don't know that there's a point to request features anymore.
You need to log in
before you can comment on or make changes to this bug.
Description
•