Update field used for collections in a backwards compatible way, sort…

[mejackreed]

…able A-Z

Fixes #810

Take 2 of #1004

For a production rollout, we need to have the sul-solr configs in place. After shipping we will need to reindex everything. This could be split into two PR's if need be, waiting for the CatalogController changes until a reindex w/ the new field takes place.

Correct 0-9 A-Z order by title (not druid)

[jkeck]

Would we also want to validate that nobody has built any browse categories from the old facet?

[mejackreed]

I'm not exactly sure how browse categories are saved, but I was hoping by leaving the legacy field in the index we wouldn't need to account for that. What do you think?

[jkeck]

Browse categories can be saved from any search result (query and/or facet). It looks like we have 50 browse categories that have been create from the collection_with_title facet.

If we make this change, and an exhibit's content is re-indexed, will this field still be there or will be be overwritten (perhaps w/ our atomic updating strategy we'll be okay, but just want to validate)?

If that is the case, then would we want to keep the configuration around (but maybe not displayed) so that when those search results are rendered the breadcrumbs/etc all render correctly?

[mejackreed]

Yep totally. Sorry I didn't make that clear up front. This strategy currently leaves the collection_with_title indexing alone, and adds collection_leading_title with the new format. Both fields should be in the schema.

[jkeck]

Okay, that sounds good. My configuration question still stands though wrt how the old facet data will be presented for the 50 existing browse categories (particularly in the search constraints/facet breadcrumb area since the helper method won't be processing that data any longer). Perhaps we can experiment with this in stage before we ship to production.

Another general question is, what is the purpose of including the druid at all? I think this may be a holdover from when the exhibits indexing code was shared with the SearchWorks codebase (and not necessarily serving any purpose in exhibits).

Just wondering if it might be a good idea to re-think the purpose of this data while we're in here juggling these facets.

[jkeck]

Also, if it's helpful, this is what I used to determine if we had browse categories w/ that particular facet (which we have 50 in production currently).

Spotlight::Search.includes(:exhibit).find_each do |search|
  q = search.query_params
  next unless q['f'] && q['f']['collection_with_title']
  puts "#{search.slug} (#{search.exhibit.slug}) : #{q}"
end