[Koha-bugs] [Bug 13914] The holds statistics report returns random data
bugzilla-daemon at bugs.koha-community.org
bugzilla-daemon at bugs.koha-community.org
Sun Apr 26 15:01:19 CEST 2015
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13914
Eivin Giske Skaaren <eskaaren at yahoo.no> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eskaaren at yahoo.no
--- Comment #2 from Eivin Giske Skaaren <eskaaren at yahoo.no> ---
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.
More information about the Koha-bugs
mailing list