VuFind
  1. VuFind
  2. VUFIND-1105

LC call number browse affected by case in cutter

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3, 2.3.1, 2.4
    • Fix Version/s: 2.3, 2.3.1, 2.4
    • Component/s: Browse
    • Labels:
      None

      Description

      Where someone lands in the LC call number browse list is affected by the case they enter the call number in. This seems to be a problem in the cutter, not so much the initial letters. Since patrons will type in whatever case, we must account for that in normalization.

        Activity

        Hide
        Tod Olson added a comment - - edited
        Here is an example from UChicago where the case in the cutter changes where the browse lands:

        PR6058.A68828 and pr6058.A68828 go to the right place
        pr6058.a68828 goes to PR6058.A23L36 2009


        Show
        Tod Olson added a comment - - edited Here is an example from UChicago where the case in the cutter changes where the browse lands: PR6058.A68828 and pr6058.A68828 go to the right place pr6058.a68828 goes to PR6058.A23L36 2009
        Hide
        Demian Katz added a comment -
        Strange -- I can't seem to reproduce that problem at Villanova (which is currently pretty close to the current master code); as you can see, all three of these links take me to the correct place:

        https://library.villanova.edu/Find/Alphabrowse/Home?source=lcc&from=PR6058.A68828
        https://library.villanova.edu/Find/Alphabrowse/Home?source=lcc&from=pr6058.A68828
        https://library.villanova.edu/Find/Alphabrowse/Home?source=lcc&from=pr6058.a68828

        Obviously, our data set is not the same as yours, so there may be some other factor at play... but whatever it is, it's not completely straightforward!
        Show
        Demian Katz added a comment - Strange -- I can't seem to reproduce that problem at Villanova (which is currently pretty close to the current master code); as you can see, all three of these links take me to the correct place: https://library.villanova.edu/Find/Alphabrowse/Home?source=lcc&from=PR6058.A68828 https://library.villanova.edu/Find/Alphabrowse/Home?source=lcc&from=pr6058.A68828 https://library.villanova.edu/Find/Alphabrowse/Home?source=lcc&from=pr6058.a68828 Obviously, our data set is not the same as yours, so there may be some other factor at play... but whatever it is, it's not completely straightforward!
        Hide
        Tod Olson added a comment -
        I was starting to wonder whether I am mis-diagnosing the locus of the problem, this certainly encourages me to reconsider. Because the symptom seems like a normalization error, and all of the tests pass in Solrmarc. Perhaps we have an older Solrmarc. Doesn't really seem likely, but worth verifying.

        Given a Solrmarc jar file, do you know a way to check the version?
        Show
        Tod Olson added a comment - I was starting to wonder whether I am mis-diagnosing the locus of the problem, this certainly encourages me to reconsider. Because the symptom seems like a normalization error, and all of the tests pass in Solrmarc. Perhaps we have an older Solrmarc. Doesn't really seem likely, but worth verifying. Given a Solrmarc jar file, do you know a way to check the version?
        Hide
        Demian Katz added a comment -
        It might be easiest to just check the file size of the SolrMarc jar against the VuFind master -- if you expect that you have the latest, you can confirm it by checking the size. If there's a mismatch, then we can dig into figuring out which version it is. (I'm pretty sure there's a way to tell, but I don't remember the details off the top of my head).

        I wonder if another possibility is that this has something to do with our changes to the Solr schema -- originally, we normalized call numbers as part of the indexing process, but now we do it at the schema level through a custom field type. If some of this indexing/schema configuration got out of sync, that seems like it might be relevant... though how that would impact us at the *alphabrowse* rather than *search* level is a mystery to me.
        Show
        Demian Katz added a comment - It might be easiest to just check the file size of the SolrMarc jar against the VuFind master -- if you expect that you have the latest, you can confirm it by checking the size. If there's a mismatch, then we can dig into figuring out which version it is. (I'm pretty sure there's a way to tell, but I don't remember the details off the top of my head). I wonder if another possibility is that this has something to do with our changes to the Solr schema -- originally, we normalized call numbers as part of the indexing process, but now we do it at the schema level through a custom field type. If some of this indexing/schema configuration got out of sync, that seems like it might be relevant... though how that would impact us at the *alphabrowse* rather than *search* level is a mystery to me.
        Hide
        Tod Olson added a comment -
        After much bashing around, I think this was a local issue with the wrong version of Solrmarc getting into our code base.

        We really need a way to ask Solrmarc what it's version is!
        Show
        Tod Olson added a comment - After much bashing around, I think this was a local issue with the wrong version of Solrmarc getting into our code base. We really need a way to ask Solrmarc what it's version is!
        Hide
        Tod Olson added a comment -
        More accurately, this should be resovled as "not really a problem."
        Show
        Tod Olson added a comment - More accurately, this should be resovled as "not really a problem."
        Hide
        Tod Olson added a comment -
        Closed
        Show
        Tod Olson added a comment - Closed

          People

          • Assignee:
            Tod Olson
            Reporter:
            Tod Olson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: