Best-hold order bugfixes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned |
Bug Description
For Evergreen 2.4+
The best-hold selection stock sort orders with "Traditional" in the name aren't quite right at modeling the traditional behavior of best-hold selection.
Traditional with Holds-go-home needs approx as the second determinant, otherwise holds whose request_lib matches the copy-in-hand's circ_lib alway try to go home even before the max foreign circulations interval has passed. With this re-ordering, we get the traditional behavior more perfectly.
The approx determinant represents a calculation that is somewhat more expensive than the hprox determinant it displaces, but best-hold selection part of checkin still completes in 0.117 seconds in a test on a wimpy VM (using 2 cores of an AMD Opteron 8380 and 2 GB of memory) with 1,000 holds targeting the same title. And approx coming first is just more correct, so it's the configuration that should be default. If sites do have performance issues, subbing pprox for approx could be appropriate if the site doesn't use proximity adjustments, or improvements could be made in the stored procedures underlying approx. But it's my expectation at this time that it's adequately performant.
Branch coming with pullrequest.
Changed in evergreen: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ senator/ traditional- approx- first