Comment 7 for bug 1441301

EG 3.3

We have been finding holds that match the query in 3 and automatically deleting them... but we had the issue come up again and I had to change my query a bit.

The query in 3 looks for meta holds where there is no metabib.metarecord.

Now we are seeing instances where the metabib.metarecord record exists, but the master_record field is null, which also seems to break the holds display. This also seems like it can come up in non-canceled holds now. I've seen examples of both canceled and non-canceled meta holds that get into this state.

The web client patron holds display breaks with a console error of
error calling method open-ils.circ.hold.details.batch.retrieve.authoritative : 500 : *** Call to [open-ils.circ.hold.details.batch.retrieve.authoritative] failed for session [-], thread trace [0]:
Can't call method "id" on an undefined value at /usr/local/share/perl/5.20.2/OpenILS/Application/Circ/Holds.pm line 3466.

I've see instances where this keeps any holds from being shown, and situations where some holds will display, but any valid holds after the bad meta hold won't get displayed... so those may be harder to detect.

This query seems to spot this new situation.

select ahr.id,ahr.request_time, ahr.cancel_time, ahr.target, ahr.usr,mm.*
,mmsm.*, bre.deleted
from action.hold_request ahr
JOIN metabib.metarecord mm ON mm.id=ahr.target
JOIN metabib.metarecord_source_map mmsm ON mmsm.metarecord=mm.id
JOIN biblio.record_entry bre ON bre.id=mmsm.source
WHERE
ahr.hold_type='M'
AND mm.master_record IS NULL
AND ahr.fulfillment_time IS null
;

Josh