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

[Mike Rylander]

On 12/29/06, Nathan Eady <eady at galion.lib.oh.us> wrote:
> Don McMorris wrote:
>
> > One method I have thought of that may accomplish the goals is to limit
> > the results and split it among different pages.  In the PAC (for
> > example), searches resulting in numerous items will be split among
> > different pages w/, say, 25 items per page.

I know Jason has experimented some with paging vs scrolling as a run
time option to the list building code.  Any middle layer
infrastructure he uses in the staff client can be used by Bill's OPAC
code too, so they'll both want to weigh in on that.  Also, they're
both still out of town, so ... ;)

>
> That was my immediate thought.  There's limited space on the screen
> anway, so the bare minimum the user is going to have to do is scroll
> in order to see them all.  There's no getting around that the user
> will have to take _some_ action, not with hundreds or potentially
> thousands of items on the list (assuming we don't want to scroll
> the list across the screen at lightning speed like in the movies).
> Could the list be propagated lazily and/or asynchronously, allowing
> the patron record to be shown before they're all retrieved, and only
> blocking if they're actually needed (e.g., if the user hits "renew
> everything" or tries to scroll to the bottom of the list)?  That
> at least would push back the performance hit from retrieving and
> showing the list to only situations where the list is actually
> needed.
>

That's exactly how it's done in the staff client today.  The entire
list of IDs (and IDs only) is retrieved, but only the visible rows are
fleshed out.  With many hundreds or even thousands of rows, though,
there's still a big performance hit in creating the dummy rows (which
magically flesh themselves when they become visible).

Paging is, I believe, where Jason is headed for interfaces where this
is a common problem, and perhaps even on demand when there are more
than, say, 100 rows.  There are other interfaces where a front line
filter (filter by date or location, etc) would help out a lot.

One thing to consider, though, is that the sorting behavior is defined
on the client side, and because the data shown is potentially from
linked tables (sometimes several distant from the core object, and not
necessarily predictable on the server in any case) sorting is not a
simple thing to do on the server side.  I'm working on a cstore
extension to address this issue (and others), but until that happens,
the client will still need to fetch all the data in order apply a
non-default sort.

> And if you're going to propagate lists lazily on patron records,
> why not in other places as well?  Say I bring up a bibliographic
> record for an extremely popular book, and there are a thousand
> items attached to it.  (Only a very large library system could
> have that many, and only for very few books, but it's not an
> inconceivable situation.)  Wouldn't the same interface be suitable
> there as well?  Why not just propagate *all* lists lazily, using
> a standard piece of list-loading infrastructure?
>

That's how it works today...  "Large" bib records are common in PINES
with 259 branches and popular books.  ;)

> (The question of why retrieving a mere 700 records causes a
> user-noticeable delay is another matter, but perhaps it's the
> placement of them in a display widget, rather than the retrieving,
> that causes the issue.  I'm afraid I don't know OpenILS well enough
> yet to know if I have even made sense here on that particular.)

Well, that's the thing.  We've been talking about list rendering, but
I'm pretty sure that's not really involved here (again, Bill and Jason
will need to chime in).

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.

Getting back to the original post, though, the problem isn't that the
software isn't doing what it's supposed to, it's that the concept of
"patron" is being conflated.  The proper solution, IMO, is going to
mean defining some other mechanism for "checking out" to a place.
Now, places don't check out items, but there is a concept of (and full
infrastructure to support) "in house use" in Evergreen today.

Here's how I would attack this situation:

1) create a sub-location for your learning center.  This, in PINES,
requires some political wrangling, but setting that aside...

2) create a copy bucket and fill it with the items you want to "move"
to your learning center

3) change the circ lib, via the batch editor to the learning center --
do not throw away the bucket!

4) if the learning center wants to keep the items for a while longer
than a normal circulation, use a (as yet to be created, but relatively
trivial) meat grinder (the working name for our "batch bucket
processor" infrastructure) to create in-house use entries for the
items in the bucket

5) when you go to call the items home (by changing the circ lib back
to the real library), run the bucket through the "in-house use" meat
grinder again _while they are still at the learning center_, and then
move the items back.

Then, when counting your circulations for the month/year/whatever, you
get the total in-house use counts from the learning center, and
there's it's circ count.  Since you don't have any idea who actually
used the items, the distinction between circulation and renewal is
immaterial, and can be ignored.

I'll annotate the bug with this as a proposed solution and see if it
gains traction with the reporting librarian.  If so, we can work on
streamlining that process -- assuming it's a common practice.

-- 
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org