On Nov 21, 2014, at 9:30 AM, Dan Wells <[email protected]> wrote:
> I’ve been mucking about in the fine code and getting a bit frustrated, so I’m
> looking for input before I move ahead.
>
> As it stands, fine generation is part of the storage API. As such, when it
> is called during checkin, it runs in its own transaction (independent of the
> circ/copy transaction). The issue is that (increasing) various pieces of the
> circ code also mangle handle fines, particular the lost item related code,
> and any code related to voiding/zeroing balances.
>
> I think we have two (not necessarily exclusive) paths to move forward:
>
> 1) Move the fine generation code into open-ils.circ and rewrite the
> necessary bits to use cstore. This would at least bring in the possibility
> of having all the checkin-time fine handling done in the same transaction,
> and thus give us a lot of flexibility in how we structure things.
> 2) Refactor the code so that more (or all) fine handling (not just
> generation, but lost bill processing, voiding, etc.) happens *after* the
> checkin transaction rather than during.
>
> I’m leaning toward #1 under the hope that it would mean fewer changes
> overall, but there are certainly merits to #2. Does anyone see anything in
> particular to suggest we should instead pursue #2 exclusively?
>
I think generating fines is a separate action that is related to checkin, but
is not directly checkin, so I would suggest using option #2. This keeps the
two pieces distinct, which creates a programatic situation that represents the
actual state of the transactions.
If checkin and fines are part of the same transaction, then a failure in fines
produces a failure in checkin. So when debugging happens, the investigation
will being at checkin and will eventually lead to fines. However, if they are
separate transactions, then any errors will lead directly to the situation
where the problem is present.
Separating the code will most likely lead to simpler code.
I am not aware of the complete checkin fines work flow, but when they are
coupled it might look like this:
checkin
if overdue
if not voiding fine
generate fine
end if
end if
end checkin
While if they are separate
checkin
if overdue
if not voiding fine
generate fine
end if
end if
This avoids one level of nesting in my simple example, and might avoid more in
the process as it actually exists within the code.
Liam
