[OPEN-ILS-DEV] Fine Generation Code Question

[Liam Whalen]

On Nov 21, 2014, at 9:30 AM, Dan Wells <dbw2 at calvin.edu> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20141121/b052dee4/attachment.htm>