Blake, there was an amount=0.0 guard missing in the upgrade script so I added that to correct an issue I was still having where a user that had all bills voided and account_adjusted away to 0 would still trigger duplicate rows.
I'm planning to add pgtap tests so we can verify the function works as designed now and as future changes are made.
That said, it seems exceptionally likely to me that having to add "IF NOT amount = 0.0 THEN ..." everywhere means that it's not data issues that we're running into, but something akin to an off-by-1 error, using < when we mean <=, or other similar logical snafu. So long as all of the (quite possibly ridiculous) tests I throw at it pass then we're probably ok to commit this as-is, but it would benefit from a fine-toothed-combing or refactoring to suss out the actual root cause of these duplicate rows.
Blake, there was an amount=0.0 guard missing in the upgrade script so I added that to correct an issue I was still having where a user that had all bills voided and account_adjusted away to 0 would still trigger duplicate rows.
My branch is here: https:/ /git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ jboyer/ lp1174498_ mmpbbt_ signoff_ pr2 / working/ user/jboyer/ lp1174498_ mmpbbt_ signoff_ pr2
I'm planning to add pgtap tests so we can verify the function works as designed now and as future changes are made.
That said, it seems exceptionally likely to me that having to add "IF NOT amount = 0.0 THEN ..." everywhere means that it's not data issues that we're running into, but something akin to an off-by-1 error, using < when we mean <=, or other similar logical snafu. So long as all of the (quite possibly ridiculous) tests I throw at it pass then we're probably ok to commit this as-is, but it would benefit from a fine-toothed- combing or refactoring to suss out the actual root cause of these duplicate rows.