CoreContainer cc = new CoreContainer(solrCoreDir, configFile);
solrCore = cc.getCore(solrCorename);

Ok, so that was more of an update, but it got me to reindex the our marc content. Our 001 fields don’t always have info, so our Systems Librarian told me just to use the 035a for the id field. There was only one problem…they had a “(Sirsi)” as a prefix to the actual number. This wouldn’t be that big of an issue, but it was causing the queries sent to Solr to be off, and I wasn’t getting any results for a detail view.

Fortunately, Solrmarc already has a facility to deal with this: PatternMaps! To pull out just the number, I changed the id definition in the vufind.properties file to

id = 035a, (pattern_map.id), first

This basically maps the id field in the schema.xml file to the 035a, using a patternMap named pattern_map.id, and only takes the first of the 035a if there are multiples. I know, there shouldn’t be, but I’ve seen funky things

Now, to add the PatternMap definition:

pattern_map.id.pattern_0 = \\(Sirsi\\)\\ (.*)=>$1

It’s just a simple regex pattern definition that takes out the “(Sirsi)” and the space between it and the actual id we’re using.

I learned a couple of interesting facts over the last couple of days. First, working on the Vufind code (well, actually it was solrmarc), Andrew and I were discussing the looping of subfields in marc records. It seemed to us that any field should only have a single subfield. So, say a 650 should only have one subfield a, b, c, etc. Much to our shagrin, we found out that specific fields can have repeating subfields. It never ceases to amaze me that what all is packed into this specification.

Also, the Dspace upgrade didn’t go so well…in fact parts of the upgrade went well, but there’s a big error I’m getting when we attempt to create the new indexes. No matter what, it errors out with a null pointer exception. I’m building a new machine to get this reconfigured. I’m just glad there aren’t that many folks using that server right now!