Open Bug 65052 Opened 21 years ago Updated 7 years ago
Improve loading times of query
.cgi with large numbers of products/components
I was discussing bugzilla installation with some people and the question came up as to what would happen with a very large number of components and/or products. Apparently redhat have a large number in their hacked up bugzilla, and query.cgi can be around 200K or so and take quite a while to load. So this installation would possibly want to add a large number of products, maybe in the hundreds, but assumedly wouldn't want this to occur. Therefore I think it's desirable to have prefs in editparams.cgi that: (a) all product listings are converted to text boxes, with links to a full product list next door (b) all component listings are converted to text boxes and a similar link This way the load time should be reasonable for them.
A corrolary: the entered product and component values would have to be error-checked against the legal_product or legal_component lists, as appropriate, and the user sent to an error page linking or incorporating the relevant full list(s) (one error page for both potential errors, please!). Also, if the official component name have initial caps (likely) and users type in component names all-lower (also likely), bug 64192, "Altering Capitalisation of a Component Name causes SQL failure", may need to be fixed for maximum robustness, by making bugzilla internally case-insensitive for product and component names at all times.
Does that mean: - We prevent case insensitive duplicate component names? What do we do about old installations? - We allow duplicate names, but if two match, use the one with correct capitalisation, or if neither has, allow the user to choose? Bug #35924 is an alternative here.
We should be able to do this in BZ3, I doubt very much we'll see this earlier.
Assignee: tara → ian
Component: Bugzilla → Bugzilla 3
Target Milestone: --- → Bugzilla 3.0
The Bugzilla 3 component is going away. We're going to depend on the Milestones for this. At the time this component was created, we didn't have milestones for Bugzilla.
Component: Bugzilla 3 → Bugzilla
Severity: normal → enhancement
Priority: -- → P3
Component: Bugzilla → Query/Bug List
Product: Webtools → Bugzilla
Version: other → unspecified
Bailing on Bugzilla 3.0 due to too many other commitments.
Assignee: ian → nobody
Assignee: nobody → query-and-buglist
Summary: Loading times with large numbers of products/components. → Improve loading times with large numbers of products/components.
Target Milestone: Bugzilla 3.0 → Bugzilla 2.24
Looks like Firefox did some strange selecting of the group radio boxes on the mass-change page when I clicked refresh in my browser before that last mass-change. This is not really a security bug. :-)
This bug is retargetted to Bugzilla 3.2 for one of the following reasons: - it has no assignee (except the default one) - we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1) - it's not a blocker If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0. If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug. If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
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 → ---
I've got (hacky) implementation for AJAX-based selection for components on bugzilla.altlinux.org (we've got ~78000 components, which is way too many :). You can use test.bugzilla.altlinux.org to play freely with it. Will post the series of (polished) patches to implement it. The general idea is as the following: In AJAX-capable browsers: * Small components lists (e.g. less than 100 (configurable)) show up as comboboxes, exactly as in current Bugzilla * Large components lists show up as editboxes with completion In AJAX-incapable browsers: * Small components lists show up as comboboxes * Large components lists show up as editboxes For the pages where set of components depends on selected products, the widget is changed depending on the amount of components for the selected set of products.
You need to log in before you can comment on or make changes to this bug.