Better use of call numbers for similar items #4119
Conversation
There was a problem hiding this comment.
Thanks, @damien-git! I'll take a little time to test this next week after the holiday. In the meantime, one thought: when I search the code for callnumber-label I find that we have quite a few test fixtures that contain a single value for the field. Is it worth updating the fixtures to make it an array just for consistency? I doubt this will change the behavior of any tests, but it might be good to keep the fixtures as realistic as possible.
There was a problem hiding this comment.
@damien-git, I haven't had a chance to try this hands-on yet, but just one more thought based on a closer look at the code. I'll wait and see if you think this is worth adjusting before I do my testing -- please let me know, and I'll test the finalized code once I hear back from you.
| int dotPos = val.indexOf("."); | ||
| if (dotPos > 0) { | ||
| val = val.substring(0, dotPos); | ||
| public List<String> getCallNumberLabel(final Record record, String fieldSpec) { |
There was a problem hiding this comment.
For backward-compatibility, how about renaming this method to getCallNumberLabels, and then keeping a getCallNumberLabel method that returns the first value from getCallNumberLabels?
This PR makes
callnumber-labelmultivalued, uses all available LCC and Dewey call numbers, and extracts different parts of them to make similar items compare call numbers at different levels of precision.It keeps backward-compatible. To take advantage of the new values, a full import should be done. But not doing it will not break anything (Solr will convert the single values to the new array format).
FOLIO users should add
952eto the call.