[OPEN-ILS-DEV] Discussion on bulk loan procedures/options/suggestions to outreach "patrons"

[Bill Erickson]

On 12/30/06, Don McMorris <don.mcmorris at gmail.com> wrote:
>
> That sounds like it would work well.  Then again, I'm not sure of the
> exact requirements the library may have.  But, the added branch would
> lessen the load against a single patron record  and the in-house-use
> would give the circulation stats.
>
> <<SNIP for the non-GMAIL Users'>>
> > In this case, it's not simply the staff client retrieving 700 rows
> > from the DB, it's the middle layer retrieving 700 circulation objects,
> > gathering surrounding payment and billing objects, sorting them into
> > batches based on due date (using DateTime, which is not a speed demon,
> > but is "correct"), retrieving and calculating fines on them, looking
> > for items on the holds shelf, etc.  As far as I can tell, the output
> > of this doesn't go into a list at all (in fact, there's not a
> > populated list on the first patron detail pane displayed by default),
> > it is used in the sidebar.  The items out list, however, uses a
> > variant of what I described above in order to split the checked out vs
> > lost/claims-returned items into separate lists ... so /those/ lists do
> > gather everything, I believe.
> >
> Perhaps a patron type (IE:ILL Agency) could be implemented that
> doesn't process some of the middle layer functions (such as fine
> processing).
> <snip>
> --Don
>

I'd like to offer a point of clarity here.  The core of the problem isn't
just the 760+ open circs on the user account in question.  The API call that
is timing out is the transaction history call ("
open-ils.actor.user.transactions.history.have_balance").  This call
"fleshes" and retrieves every transaction, open or closed, on the user and
attempts to sort and mangle the data in the middle layer.  This user
currently has 2168 transactions in the database, so the middle layer times
out before it even collects all of the data.  We could re-engineer the
middle layer to retrieve the data as a stream to prevent it from timing out,
but then the gateway would time out -- basically, it just takes too long to
shuffle that much data around.

Apart from changing the way these user accounts are handled, the only
solution I can see would be to move the transaction history calculations
closer to the database - i.e. a storage method.  This worked great for the
user fines summary API method wich used to time out on our test accounts
until we shoved the logic down into a storage method.

We've also briefly discussed the idea of a "money" application, whose job it
would be to provide an abstraction layer and accounting logic over the
different types of transactions.  Could this app talk directly to the
database?  It seems like that could provide speed benefits all around.

As an aside, I'm not terribly concerned about slow renedering of checked-out
items for these "special" accounts, since that seems more like a job for
reports.  I am concerned about slowness with rendering real patrons with
lots of closed transactions on their account, though, admittedly, it will
take quite a while to even get hundereds (much less thousands) of closed
transactions on an account.




-- 
Bill Erickson
PINES Systems Developer
Georgia Public Library Service
billserickson at gmail.com
http://open-ils.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070103/5dc4a8c5/attachment-0001.html