An example of what I mean can be found here: user/gmcharlt/lp1890822_move_penalty_calculation, with the tradeoff that if the checkout or renenwal fails because of a newly-calculated penalty, the new penalty will get rolled back.
This may be good enough for now, but if not, options I see include
- refactoring run_method so that the first thing it does (for checkouts and renewals) is identify the user for all possible types of input parameters. Note that if this approach is taken that it will be important to make sure that the big transaction maintained by $circulator gets opened (again?) after the penalties are recalculated
- stick in an out-of-main-transaction recalculation of the user penalties if the checkout or renewal fails (either for any reason, or specifically because of a blocking system penalty)
An example of what I mean can be found here: user/gmcharlt/ lp1890822_ move_penalty_ calculation, with the tradeoff that if the checkout or renenwal fails because of a newly-calculated penalty, the new penalty will get rolled back.
This may be good enough for now, but if not, options I see include
- refactoring run_method so that the first thing it does (for checkouts and renewals) is identify the user for all possible types of input parameters. Note that if this approach is taken that it will be important to make sure that the big transaction maintained by $circulator gets opened (again?) after the penalties are recalculated main-transactio n recalculation of the user penalties if the checkout or renewal fails (either for any reason, or specifically because of a blocking system penalty)
- stick in an out-of-