Wow ... either i'm a huge idiot and everyone has just been really polite about it in most threads, or something about this thread in particular made me really stupid.
(Luis: i'm sorry for all the things i have said so far in this email thread that were a complete waste of your time - hopefully this email will make up for it) Idiocy #1... : > Solr can : > not reasonably compute stats on a multivalued field : : Wasn't that added here? : https://issues.apache.org/jira/browse/SOLR-1380 Yes, correct. I didn't realize that functionality had ever been added, but it was and it does still work just fine in Solr 3.5 (you can see this in any of the StatsComponentTest methods that call doTestMVFieldStatisticsResult) Idiocy #2... >> Subject : Re: r1201855 broke stats.facet on long fields ...in spite of this subject, and multiple references to "stats.facet" in Luis's original email I complely overlooked the entire crux of the Luis's problem. I thought the issue was that he couldn't get *stats* on a multi-valued field, I didn't realize that it was the "stats.facet" param that had started failing for him in Solr 3.5 I believe that the intention of the code Luis quoted, which was committed as part of SOLR-1023 in r1201855, was actually to pre-emptively avoid the problems mentioned in SOLR-1782 (which Luis actually mentioned and i *still* didn't realize this was about stats.facet - Idiocy#3) ... >> if (facetFieldType.isTokenized() || facetFieldType.isMultiValued()) { >> throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, ...given the way the stats faceting code works, that sanity check does make sense, and seems like a good idea. but the crux of the issue in Luis's case... >> <fieldType name="long" class="solr.TrieLongField" precisionStep="0" omitNorms="true" positionIncrementGap="0" /> >> <field name="ts" type="long" indexed="true" stored="true" required="true" /> ...seems to be that the isTokenized() test that's failing (and *not* the isMultiValued() check that i immediatley assumed - Idiocy#4) because TrieField.isTokenized() is hardcoded to return true. I *think* TrieField.isTokenized should be changed to depend on the value of the precisionStep, but i'm not sure what all the ramifications of that are just yet -- but i've opened SOLR-2976 to look into it. -Hoss
