If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Make Bugzilla::Bug work with Bugzilla::Object->new_from_list

RESOLVED WORKSFORME

Status

()

Bugzilla
Creating/Changing Bugs
--
enhancement
RESOLVED WORKSFORME
13 years ago
3 years ago

People

(Reporter: Max Kanat-Alexander, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs)

Dependency tree / graph

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
We need to be able to have an object that can represent a list of bugs in a way
that will not break performance. It needs to be a list of Bug objects, but they
can't be each read from the database individually.

I think it would be pretty simple to create, actually. We'd just have to break
out the SQL code from _initBug and modify it to either take a single id or a
list. Or, it could take a $where_part argument, using an IN or a = depending on
whether it was being called from BugList or Bug.

Then we'd make _initBug itself just take a single hashref containing the
necessary fields, and we could easily call that a bunch of times from BugList.

I think that BugList should be allowed to call private functions within Bug,
because they're pretty much in the same "package."

After the initial creation of the BugList, we could create some clever methods
on the list to collect other Bug information in a performant fashion, if *and
only if* we found that it was needed for performance reasons.
(Reporter)

Updated

13 years ago
Blocks: 288296

Comment 1

11 years ago
Max, now that we have Object->new_from_list(), I think we can WONTFIX this bug. Agreed?
(Reporter)

Comment 2

11 years ago
Actually, instead, let's make this bug into our bug for making Bugzilla::Bug work with new_from_list.
Summary: Bugzilla::BugList object for creating lists of Bugs → Make Bugzilla::Bug work with Bugzilla::Object->new_from_list

Updated

11 years ago
Blocks: 355838

Updated

10 years ago
Target Milestone: --- → Bugzilla 4.0

Comment 3

8 years ago
Created attachment 392705 [details] [diff] [review]
patch, v1
Assignee: create-and-change → LpSolit
Status: NEW → ASSIGNED
Attachment #392705 - Flags: review?(mkanat)
(Reporter)

Comment 4

8 years ago
Comment on attachment 392705 [details] [diff] [review]
patch, v1

Actually, I don't want new_from_list to use {error}. Instead I want to stop using {error} in new() and have some sort of eval system or some other function that returns a specific return value based on what error we experienced, or something like that.
Attachment #392705 - Flags: review?(mkanat) → review-

Comment 5

8 years ago
(In reply to comment #4)
You are pretty vague. Could you explain a bit further? For now, the goal is to get a list of bugs faster thanks to new_from_list(). This one can be updated at the same time as new() when the "schema" changes.
(Reporter)

Updated

8 years ago
Depends on: 509734

Updated

7 years ago
No longer blocks: 355838

Updated

7 years ago
Assignee: LpSolit → create-and-change

Updated

6 years ago
Status: ASSIGNED → NEW

Comment 6

5 years ago
We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.
Target Milestone: Bugzilla 4.4 → Bugzilla 5.0

Comment 7

3 years ago
grep -rs "Bugzilla::Bug->new_from_list" *

returns plenty of results
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME

Updated

3 years ago
Target Milestone: Bugzilla 5.0 → ---
You need to log in before you can comment on or make changes to this bug.