Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Callnumber improvements #305

Closed
wants to merge 12 commits into from
Closed

Callnumber improvements #305

wants to merge 12 commits into from

Conversation

demiankatz
Copy link
Member

Call number handling can be simplified due to improvements in SolrMarc and the AlphaBrowse handler.

@demiankatz
Copy link
Member Author

TODO: introduce 'callnumber-sort' field and investigate the possibility of eliminating the plain 'callnumber' field.

@demiankatz
Copy link
Member Author

Okay, I believe this is now complete, but I'll give it a few days for review before merging.

@todolson
Copy link

todolson commented Mar 9, 2015

Generally, I think this looks pretty okay, but will try to test on some local data this week. There are two minor questions in my mind:

  • The callnumber field type has a very general name, but cannot be general use as spaces are stripped at index and query time, so is that the right name? (Of course I don't have a better name to offer.)
  • I foresee wanting a way to search with and without call number prefixes, like f for folio, and these will vary somewhat between libraries. Do you see the pattern in the callnumber field type definition as a place where that could happen, and be reasonable configured by an individual site?

@demiankatz
Copy link
Member Author

Thanks, Tod.

Regarding the callnumber field type, what would you think of searchable-callnumber, callnumber-search, or some variation like that? I'm happy to change it.

Regarding prefixes, I imagine the best approach would depend on the complexity of the prefixing system. It would certainly be possible to add a pattern to strip off prefixes, assuming a simple and easily identifiable scheme. Alternatively, it might also be possible to handle them through munge rules in searchspecs.yaml, if a solution were necessary that didn't involve modifying the Solr schema. I don't think there's any simple way of handling it generically, so some degree of local customization is likely to be necessary no matter what.

@todolson
Copy link

todolson commented Mar 9, 2015

Yes, I think you're on the right track with the name of the field type. Following the camel case convention of the text* fields types is probably the way to go. We only have one call number, but still. Something like callnumberSearch or callnumberSearchable seems reasonable and descriptive.

@demiankatz
Copy link
Member Author

Done -- I went with "callnumberSearch" for brevity. Also added a comment on the fieldtype definition for good measure.

@demiankatz
Copy link
Member Author

Manually merged.

@demiankatz demiankatz closed this Mar 13, 2015
@demiankatz demiankatz deleted the callnumber-improvements branch June 25, 2015 19:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants