doing SIP2 lookup of a patron who has a metarecord hold can fail
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
High
|
Unassigned | ||
2.6 |
Fix Released
|
High
|
Unassigned |
Bug Description
When doing a SIP2 patron information lookup of a patron that has an active metarecord hold, the request can time out. This is because the SIP code calls open-ils.
SELECT record,
item_type,
item_form,
quality,
FIRST(
FROM (
SELECT rd.record,
fr.tag,
fr.value,
fr.ind2
FROM metabib.
JOIN biblio.record_entry br ON (sm.source = br.id)
JOIN metabib.full_rec fr ON (fr.record = br.id)
JOIN metabib.
WHERE sm.metarecord = '702263'
AND (( EXISTS (
) OR NOT EXISTS (
))
OR EXISTS ((
)
OFFSET 0
) AS x
WHERE tag = '245'
AND subfield = 'a'
GROUP BY record, item_type, item_form, quality
ORDER BY
CASE
WHEN item_type IS NULL -- default
WHEN item_type = '' -- default
WHEN item_type IN ('a','t') -- books
WHEN item_type = 'g' -- movies
WHEN item_type IN ('i','j') -- sound recordings
WHEN item_type = 'm' -- software
WHEN item_type = 'k' -- images
WHEN item_type IN ('e','f') -- maps
WHEN item_type IN ('o','p') -- mixed
WHEN item_type IN ('c','d') -- music
WHEN item_type = 'r' -- 3d
END,
title ASC,
quality DESC;
This, in turn, can have an atrocious query plan:
Sort (cost=180742258
Sort Key: (CASE WHEN (x.item_type IS NULL) THEN 0 WHEN (x.item_type = ''::text) THEN 0 WHEN (x.item_type = ANY ('{a,t}'::text[])) THEN 1 WHEN (x.item_type = 'g'::text) THEN 2 WHEN (x.item_type = ANY ('{i,j}'::text[])) THEN 3 WHEN (x.item_type = 'm'::text) THEN 4 WHEN (x.item_type = 'k'::text) THEN 5 WHEN (x.item_type = ANY ('{e,f}'::text[])) THEN 6 WHEN (x.item_type = ANY ('{o,p}'::text[])) THEN 7 WHEN (x.item_type = ANY ('{c,d}'::text[])) THEN 8 WHEN (x.item_type = 'r'::text) THEN 9 ELSE NULL::integer END), (first(
-> HashAggregate (cost=180742258
-> Subquery Scan on x (cost=28127.
-> Limit (cost=28127.
(79 rows)
All this to (in the case of the SIP2 request) just grab a title.
Evergreen 2.6
Changed in evergreen: | |
assignee: | nobody → Mike Rylander (mrylander) |
importance: | Undecided → High |
Changed in evergreen: | |
milestone: | 2.next → 2.7.0-alpha1 |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
It looks like that the patch for bug 1296937 will address this problem when the SIP client is only requesting the counts of available and unavailable hold requests. However, it's not a complete solution for this bug, since the SIP client could also specifically request detailed information about held titles, in which case this bug will be triggered.