From: Naomi D. <nd...@st...> - 2008-08-11 18:37:18
|
Hi Andrew, Thanks for these answers, and for the link. FYI, the main reasons I have for wanting to shrink the index are: 1. I'm a tidy freak. 2. To avoid huge RAM requirements (probably a non-issue once we get our new hardware) 3. To reduce indexing time (optimization takes longer when the index is bigger). 4. For our temporary disk space crunch. As far as I could tell, callnumber-a was an exact duplicate of callnumber, and wasn't used anywhere in the code. Nor could I find the code for callnumber-x-code. But I'm no php or AJAX expert. Reading the SOLR documentation, facets frequently don't need to be stored, since the faceting mechanism returns the values in the search results. Hence my belief that callnumber-first doesn't need to be stored: whenever you need it, there it is. :-) - Naomi On Aug 11, 2008, at 10:54 AM, Andrew Nagy wrote: >> I've been working on implementing call numbers locally, and have a >> bunch of questions: >> >> callnumber-a: is it used? >> callnumber-first-code: is it used? >> callnumber-subject-code: is it used? > > Yes, they are all used for faceting. > >> >> >> callnumber-subject: does the code to display this (after callnumber- >> first is select) work? >> >> callnumber-label: does the code to display this (after callnumber- >> subject is select) work? > > Yes - they are all functional at this point. > You can see an example at the following: > http://beta.library.villanova.edu/Find/Search/Home? > type=all&filter[]=callnumber-first:%22P%22&filter[]=callnumber- > subject:%22PQ%22 > > If you look at the right hand side you will notice that I have > narrowed my results down to the P call number range and then again > to the PQ call number range. > Currently, the top level ranges are identified with their english > equivelant. With VuFind 1.0 (mainly due to SolrMarc) the 2nd level > range will also have english equivalents. > >> >> callnumber-first: I don't think it needs to be stored ... > > All callnumber fields should be store and indexed as some are used > for searching. Since the data is so small and index size should not > have effect on search performance - I think it is best to have them > all indexed and stored. This will be most beneficial for future use > incase all fields end up being used for searching. > > Andrew Naomi Dushay nd...@st... |