You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Luis Neves <lu...@gmail.com> on 2011/12/08 23:03:07 UTC
r1201855 broke stats.facet on long fields
Hello,
I've a "long" field defined in my schema:
<fieldType name="long" class="solr.TrieLongField" precisionStep="0"
omitNorms="true" positionIncrementGap="0" />
<field name="ts" type="long" indexed="true" stored="true" required="true" />
Before r1201855 I could use "stats.facet=ts" which allowed me to have a
timeseries of sorts, now I get an error:
"Stats can only facet on single-valued fields, not:
ts[long{class=org.apache.solr.schema.TrieLongField,analyzer=org.apache.solr.analysis.TokenizerChain,args={precisionStep=0,
positionIncrementGap=0, omitNorms=true}}]"
Is there any hope of having the old behavior back?
Looking at the changed code I see this:
if (facetFieldType.isTokenized() || facetFieldType.isMultiValued()) {
throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
"Stats can only facet on single-valued fields, not: " + facetField
+ "[" + facetFieldType + "]");
}
this seem to also "fix" SOLR-1782.
--
Luis Neves
Re: r1201855 broke stats.facet on long fields
Posted by Chris Hostetter <ho...@fucit.org>.
: > (If that doens't fix the problem for you.
:
: It doesn't.
Definitely odd...
: > please file a Jira bug with as much details as possible about your setup
: > (ideally a fully usable solrconfig.xml+schema.xml that demonstrates your
: > problem) because the StatsComponentTest most certainly already tests that
: > stats can be computed on a multiValued="false" TrieLongField with
: > precisionsStep="0")
:
: I will try to set up a reproducible test case.
Thanks ... or maybe take a look at the existing StatsComponentTest (and
the schema.xml it uses) and see if you can spot what you are doing that it
doesn't cover? (the ideal bug report would include a patch to that test that
causes it to fail, but just a comment pointing out what you are doing
differently then that test to get your failure would be helpful)
-Hoss
Re: r1201855 broke stats.facet on long fields
Posted by Luis Neves <lu...@gmail.com>.
On 12/08/2011 11:16 PM, Chris Hostetter wrote:
>
> ...so if you don't have a version param, or your version param is "1.0"
> then that would explain this error
I have the version param set to "1.4".
> (If that doens't fix the problem for you.
It doesn't.
> then i'm genuinely baffled, and
> please file a Jira bug with as much details as possible about your setup
> (ideally a fully usable solrconfig.xml+schema.xml that demonstrates your
> problem) because the StatsComponentTest most certainly already tests that
> stats can be computed on a multiValued="false" TrieLongField with
> precisionsStep="0")
I will try to set up a reproducible test case.
Thanks!
--
Luis Neves.
Re: r1201855 broke stats.facet on long fields
Posted by Chris Hostetter <ho...@fucit.org>.
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
Re: r1201855 broke stats.facet on long fields
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Thu, Dec 8, 2011 at 6:16 PM, Chris Hostetter
<ho...@fucit.org> wrote:
> Solr can
> not reasonably compute stats on a multivalued field
Wasn't that added here?
https://issues.apache.org/jira/browse/SOLR-1380
-Yonik
http://www.lucidimagination.com
Re: r1201855 broke stats.facet on long fields
Posted by Chris Hostetter <ho...@fucit.org>.
: I've a "long" field defined in my schema:
:
: <fieldType name="long" class="solr.TrieLongField" precisionStep="0"
: omitNorms="true" positionIncrementGap="0" />
:
: <field name="ts" type="long" indexed="true" stored="true" required="true" />
:
: Before r1201855 I could use "stats.facet=ts" which allowed me to have a
: timeseries of sorts, now I get an error:
Since your field type doesn't explicitly state "multiValued="true|false"
Solr's behavior in parsing the schema.xml is driven by the "version" param
on the <schema/> tag. From the example in Solr 3.5...
<schema name="example" version="1.4">
<!-- attribute "name" is the name of this schema and is only used for display purposes.
Applications should change this to reflect the nature of the search collection.
version="1.4" is Solr's version number for the schema syntax and semantics. It should
not normally be changed by applications.
1.0: multiValued attribute did not exist, all fields are multiValued by nature
1.1: multiValued attribute introduced, false by default
1.2: omitTermFreqAndPositions attribute introduced, true by default except for text fields.
1.3: removed optional field compress feature
1.4: default auto-phrase (QueryParser feature) to off
-->
...so if you don't have a version param, or your version param is "1.0"
then that would explain this error: you've told Solr that this field is
multivalued (even though you may not be using it that way) and Solr can
not reasonably compute stats on a multivalued field (the fact that it may
have done so prior to r1201855 was most likely a failure to error check)
-- adding multiValued="false" to your "<field/> should make this work.
(If that doens't fix the problem for you, then i'm genuinely baffled, and
please file a Jira bug with as much details as possible about your setup
(ideally a fully usable solrconfig.xml+schema.xml that demonstrates your
problem) because the StatsComponentTest most certainly already tests that
stats can be computed on a multiValued="false" TrieLongField with
precisionsStep="0")
-Hoss