https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41801
--- Comment #12 from Martin Renvoize (ashimema) <[email protected]> --- Created attachment 194989 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194989&action=edit Bug 41801: (QA follow-up) Replace MAX subquery with in-memory array count for rank clamping The lowestPriority rank-clamping block fired a second SQL query to get max(priority) WHERE lowestPriority=0 and used that value as both a threshold and a splice index. This was fragile: if priorities had become discontiguous (e.g. due to a race or a bug elsewhere), the DB priority value would not match the 1-based position in @priority, and the splice could land the hold in the wrong slot. The @priority array already contains all the information needed: it is sorted lowestPriority ASC so the count of rows where lowestPriority=0 is exactly the number of non-lowest holds, which equals the last valid rank for a normal hold. Fetch lowestPriority in the existing SELECT and use scalar grep { !$_->{lowestPriority} } @priority instead. This eliminates the extra DB round-trip and makes the clamping operate on the same data snapshot that will be written back. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
