[Koha-bugs] [Bug 17138] New: UpdateFine() modyfies existing fine records even when there is no need

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17138

            Bug ID: 17138
           Summary: UpdateFine() modyfies existing fine records even when
                    there is no need
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5 - low
         Component: Circulation
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: abl at biblos.pk.edu.pl
        QA Contact: testopia at bugs.koha-community.org
                CC: gmcharlt at gmail.com, kyle.m.hall at gmail.com

In C4/Overdues.pm:

  574:     # we're updating an existing fine.  Only modify if amount changed

  577:     if ( $data->{'amount'} != $amount ) {

for some numbers (e.g. 5.60) the comparison in line 577 fails
($data->{'amount'} is decimal(28,6) i.e. a string, and $amount may be a
floating point number with no exact binary representation). E.g. when the fine
amounts are multiple of 0.20, it fails for the 33.3% of the amounts (on
average).

Depending on the fine charging settings, this may trigger unnecessary database
writes (and a lot of them). If 'Fine Charging Interval' is 1 day, this has very
little practical consequences (misc/cronjobs/fines.pl script is usually run
once per day, and all fines need an increase anyway). But if the charging
interval is longer, e.g. 7 days, in a given day amount changes only for the 1/7
of the fines (again, on average), and over 60% of the database writes would be
redundant.

To reproduce:
1) run misc/cronjobs/fines.pl
2) add

   warn "AMOUNT ".$data->{'amount'}." vs $amount";

below line 577 in C4/Overdues.pm
3) run misc/cronjobs/fines.pl again
4) you'll see some warnings like 'AMOUNT 5.600000 vs 5.6'

or: dump accountlines table after step 1), run the script 2nd time, dump the
table again and compare the contents - some of the records would have a
different timestamp.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.