Hi Henrik, If I understand the question correctly (case-insensitive sorting of the facet values), then this is the limitation of the current Facet component.
You can see the full implementation at: https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/handler/component/FacetComponent.java#L818 If you are comfortable with Java code, the easiest thing might be to copy/fix the component and use your own one for faceting. The components are defined in solrconfig.xml and FacetComponent is in a default chain. See: https://github.com/apache/lucene-solr/blob/trunk/solr/example/solr/collection1/conf/solrconfig.xml#L1194 If you do manage to do this (I would recommend doing it as an extra option), it would be nice to have it contributed back to Solr. I think you are not the only one with this requirement. Regards, Alex. Personal website: http://www.outerthoughts.com/ LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch - Time is the quality of nature that keeps events from happening all at once. Lately, it doesn't seem to be working. (Anonymous - via GTD book) On Mon, Jul 15, 2013 at 10:08 AM, Henrik Ossipoff Hansen < h...@entertainment-trading.com> wrote: > Hello, first time writing to the list. I am a developer for a company > where we recently switched all of our search core from Sphinx to Solr with > very great results. In general we've been very happy with the switch, and > everything seems to work just as we want it to. > > Today however we've run into a bit of a issue regarding faceted sort. > > For example we have a field called "brand" in our core, defined as the > text_en datatype from the example Solr core. This field is copied into > facet_brand with the datatype string (since we don't really need to do much > with it except show it for faceted navigation). > > Now, given these two entries into the field on different documents, "LEGO" > and "bObles", and given facet.sort=index, it appears that LEGO is sorted as > being before bObles. I assume this is because of casing differences. > > My question then is, how do we define a decent datatype in our schema, > where the casing is exact, but we are able to sort it without casing > mattering? > > Thank you :) > > Best regards, > Henrik Ossipoff >
