http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13914
Eivin Giske Skaaren <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Eivin Giske Skaaren <[email protected]> --- I am still very new to Koha so please excuse (and explain) if I am thinking wrong here: The query that gets fired when testing this bug looks like this: (SELECT case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end line, reserves.branchcode col, COUNT(*) calculation FROM reserves LEFT JOIN borrowers USING (borrowernumber) WHERE reservedate >= '2015-04-15' AND reservedate <= '2015-04-30' AND (( case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end = '3' ) OR ( case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end = '1' ) OR ( case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end = '4' ) OR ( case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end = '2' ) OR ( case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end = '5' ) ) GROUP BY line, col ) UNION (SELECT case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end line, old_reserves.branchcode col, COUNT(*) calculation FROM old_reserves LEFT JOIN borrowers USING (borrowernumber) WHERE reservedate >= '2015-04-15' AND reservedate <= '2015-04-30' AND (( case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end = '3' ) OR ( case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end = '1' ) OR ( case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end = '4' ) OR ( case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end = '2' ) OR ( case when priority>0 then 1 when priority=0 then (case when found='f' then 4 when found='w' then (case when cancellationdate is null then 3 else 5 end ) else 2 end ) else 6 end = '5' ) ) GROUP BY line, col ) ORDER BY line, col So one way of getting line numbers that are not unique for the same col is if priority is set to >0 for an item in the old_reserves table. Question: Should priority ever be anything else than 0 for an item in the old_reserves table? The patch still gets the same SQL result and then tries to solve the problem by using the value of line as hash key and adds the values of calculation from any rows with the same line value. But this results in the wrong values being added given my example with priority for an item in the old_reserves table being set to >0. The query will as in Jonathan's example create rows with line value 1 for both the reserves table and the old_reserves table, so the line value should not be used as the hash key since it will then add values from the different tables to the calculation field. Perhaps this is better solved by getting the SQL correct for the use case, perhaps by adding a field to the result set that is unique? Also by looking at the reservestatus I suspect that something else is wrong here since line=1 corresponds to 1-placed which should be wrong for anything in the old_reserves table. This patch then does not solve the problem if the things that I have assumed are correct. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://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/
