Held records - logs should output reason for being held

[patrickzurek]

JIRA issue created by: rcook Originally opened: 2011-08-30 06:59 PM

Issue body: (nt)

[patrickzurek]

JIRA Coment by user: rcook JIRA Timestamp: 2011-08-30 07:10 PM

Comment body:

The logs should write information about why a record is being held.

If it is waiting for a parent record to arrive, list what it is waiting for. If it has some parent information but not all, list the parent info that it does have. For 014 Tags, please write out info to the logs, such as the first and 2nd indicator (MARC) and content as below.

For example, we think the following has a data problem with leading zeros in the "a" subfield with first indicator of "1".

00035789/marc:subfield This will help further diagnosis.

[patrickzurek]

JIRA Coment by user: rcook JIRA Timestamp: 2011-08-31 02:29 PM

Comment body:

Just confirming that this is a true bound-with in Voyager and that everything is coded correctly. Voyager has the holdings record linked to all 6 bibs – the one in the 004 and all of the 014 bib IDs. If this one isn’t working properly than we’ve got a problem.

From: Cook, Randall Sent: Tuesday, August 30, 2011 4:56 PM To: Bowen, Jennifer; Brand, John Cc: Anderson, Benjamin D; Lindahl, David Subject: held holdings and true bound withs

HELD Normalized holdings record for a true bound with. http://128.174.70.247:8080/MetadataServicesToolkit/st/viewRecord.action?recordId=11918396&query=&searchXML=false&selectedFacetNames=|successor&selectedFacetValues=|24038395&rowStart=0&startPageNumber=1&currentPageNumber=1

This holdings 4567767 is bound with several bibs (yellow). John, Is there a way to tell which parent it is waiting for (e.g. why it is held)? Jennifer, I assume that we could have cataloging mistakes that could leave a 014 in the holdings record by mistake? If so, we certainly would need to know which record it is being held waiting for so that we could research and take corrective action.

4321304/marc:controlfield 20090805114528.0/marc:controlfield 0908054u 8 1001uu 0901128/marc:controlfield 4321350/marc:subfield /marc:datafield 4321432/marc:subfield /marc:datafield 4321443/marc:subfield /marc:datafield 4321449/marc:subfield /marc:datafield 4321454/marc:subfield Note: Copying Dave as he was a little interested in how I am looking at these. It is mostly very time intensive poking.

[patrickzurek]

JIRA Coment by user: jbrand JIRA Timestamp: 2011-12-08 03:12 PM

Comment body:

I'm not sure I understand the requirements for this one. Assigning back to Randy - can you answer these questions?

When should this information go to the log? At the time the record is held? Should it spew updated information each time a related bib comes in? Would this information always be logged or have to be specially turned on to log? (configurable or a certain log level?) For instance, if there are many of these, and we are always logging it, it could make the logs hard to go through.

[patrickzurek]

JIRA Coment by user: rcook JIRA Timestamp: 2011-12-08 03:46 PM

Comment body:

This is probably something that Chris should tackle in conjunction with 827 and his other Held Holding work. We have a real world case right now. I think we should build out this logging to capture the data that would be helpful in trying understand why we are holding all the records that we are.

Right now we know nothing, just that a record is held but nothing about why. Ideally, the log would say "Awaiting parent record 1234" or something useful so that further research can be taken. I think what is captured is informed by the pieces of data that the code bases uses to make decisions about holding/not holding a record.

You should have the logging be optional so that once we have our software working well it could be turned off.