https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33795 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |kyle@bywatersolutions.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33795 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |minor -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33795 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33795 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|33796 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33796 [Bug 33796] Holds Queue builder never looks at any but the least cost branch of the transport cost matrix -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33795 Sam Lau <samalau@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151535|0 |1 is obsolete| | --- Comment #2 from Sam Lau <samalau@gmail.com> --- Created attachment 151654 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151654&action=edit Bug 33795: Holds Queue builder should do cheap checks before expensive checks The holds queue builder runs many checks in a somewhat arbitrary order. We should order those checks such that the most expensive checks are at the end and can be avoided if a faster check fails. Test Plan: 1) prove t/db_dependent/HoldsQueue.t 2) Apply this patch 3) prove t/db_dependent/HoldsQueue.t 4) Tests still pass! Signed-off-by: Sam Lau <samalau@gmail.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33795 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33795 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA Severity|minor |enhancement --- Comment #4 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Sorry, I didn't have the time to finish this message yesterday to avoid you coming back twice to this ticket: In addition to the conflict: the tests don't cover the changes, one can straight up comment the lines that the patch would have changed and the tests still passe. 😱 So, test plan invalid. --- About the aim of the patch: «We should order those checks such that the most expensive checks are at the end and can be avoided if a faster check fails.» It's not necessary faster in practice to have the checks ordered by cost. It can be better to have the most likely to succeed first. Because fast checks that very rarely are reached in the original code would actually be an additional time if we just order by speed. But!: If they are so cheap compared to the more expensive checks, then it doesn't make a difference. And the few times they succeed before the more expensive checks make up for that and will be a net gain. Assuming they don't often succeed, which will be eventually the next question. Now the question is: how cheap are they compared to the other checks? To me it looks like they just access already available object attributes that I guess are loaded eagerly by the ORM. And the other checks need to fetch stuff in the DB so the difference is massive. What do you think? -- You are receiving this mail because: You are watching all bug changes.