John, good points about retaining the current_copy for cancelled holds for the purposes of clearing the holds shelf and troubleshooting. I can see the value there, but it seems like retaining current_copy in every hold makes it more cumbersome to get the pertinent data out of action.hold_request.
A quick query in our production database shows hundreds of holds with the same current_copy, fulfilled or cancelled long ago. I'm not sure we need to keep that data back to the beginning of holds.
All that said, I tested both patches with production data and am adding my signoff to the nulls last patch as it seems to perform just a bit better. Here's my signoff branch:
John, good points about retaining the current_copy for cancelled holds for the purposes of clearing the holds shelf and troubleshooting. I can see the value there, but it seems like retaining current_copy in every hold makes it more cumbersome to get the pertinent data out of action. hold_request.
A quick query in our production database shows hundreds of holds with the same current_copy, fulfilled or cancelled long ago. I'm not sure we need to keep that data back to the beginning of holds.
All that said, I tested both patches with production data and am adding my signoff to the nulls last patch as it seems to perform just a bit better. Here's my signoff branch:
https:/ /git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ mmorgan/ lp1827250_ last_captured_ hold_fix_ nulls_last_ signoff