[Koha-bugs] [Bug 25891] build_holds_queue can be daemonised

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25891

Christopher Brannon <cbrannon at cdalibrary.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cbrannon at cdalibrary.org

--- Comment #7 from Christopher Brannon <cbrannon at cdalibrary.org> ---
I'm trying to understand why Sally doesn't have a cron job rebuild the queue at
least hourly.  From her description, it sounds like it is only run once a day,
unless I am missing something.

With that said, I understand the randomize thing, but from the perspective of a
consortium, we stay as far away from randomizing as we can.  It seems like if
you are not going to randomize, and you are going for the most efficient
transfer, you would want that info at the time of running the report.

Yes, we will ALWAYS have items that disappear from the list - a library opens,
and on that day, their item is the better candidate.  Those changes make sense,
and our libraries come to expect it.  On average, we might get 3 pulled holds
at most that don't trigger the hold on the list because another library just
checked in a copy and filled the hold.  To me, this is more annoying, because
it means that ANY item on a record hold request can supersede the efficiency of
the queue, thus making the hold being filled less efficient than was designed
by the transport cost matrix.

In my opinion, if a system is going to use the transport cost matrix,
randomization is out the window - and holds should be locked in according to
the matrix.  If a library can't fill that hold, they need a way to mark it as
unfillable, and the matrix moves on to the next most efficient candidate.  This
would stop other libraries from making less efficient responses, and libraries
would be dealing with less items that are already filled elsewhere.

But back to the daemonized report - If the system would just tell you what
needs to be pulled at the time of the report (without having to build this in
the background x times a day), it would only have to do this as many times as
the report is run.  With the transport cost matrix locking request (and with
the option of a library passing on a request due to an issue), this would be a
very appealing layout for us.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.