You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (Updated) (JIRA)" <ji...@apache.org> on 2011/12/20 03:07:30 UTC
[jira] [Updated] (SOLR-2976) stats.facet no longer works on single
valued trie fields that don't use precision step
[ https://issues.apache.org/jira/browse/SOLR-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man updated SOLR-2976:
---------------------------
Description:
As reported on the mailing list, 3.5 introduced a regression that prevents single valued Trie fields that don't use precision steps (to add course grained terms) from being used in stats.facet.
two immediately obvious problems...
1) in 3.5 the stats component is checking if isTokenzed() is true for the field type (which is probably wise) but regardless of the precisionStep used, TrieField.isTokenized is hardcoded to return true
2) the 3.5 stats faceting will fail if the FieldType is multivalued - it doesn't check if the SchemaField is configured to be single valued (overriding the FieldType)
so even if a user has something like this in their schema...
{code}
<fieldType name="long" class="solr.TrieLongField" precisionStep="0" omitNorms="true" />
<field name="ts" type="long" indexed="true" stored="true" required="true" multiValued="false" />
{code}
...stats.facet will not work.
was:
regardless of the precisionStep used, TrieField.isTokenized is hardcoded to return true -- so even if a user has something like this in their schema...
{code}
<fieldType name="long" class="solr.TrieLongField" precisionStep="0" omitNorms="true" />
<field name="ts" type="long" indexed="true" stored="true" required="true" multiValued="false" />
{code}
...any code paths that are driven by isTokenized will think their may be multiple terms per document when in reality there is at most one.
we should consider redefining TrieField.isTokenized to be something like...
{code}
@Override
public boolean isTokenized() {
return Integer.MAX_VALUE != precisionStep;
}
{code}
Summary: stats.facet no longer works on single valued trie fields that don't use precision step (was: TrieField.isTokenized returns true regardless of precisionStep)
I started looking into this today and realized there are additional problems with the stats faceting code changed in 3.5 as it relates to tried fields and the original problem report. Updating the summary/description to expand the scope
> stats.facet no longer works on single valued trie fields that don't use precision step
> --------------------------------------------------------------------------------------
>
> Key: SOLR-2976
> URL: https://issues.apache.org/jira/browse/SOLR-2976
> Project: Solr
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Hoss Man
>
> As reported on the mailing list, 3.5 introduced a regression that prevents single valued Trie fields that don't use precision steps (to add course grained terms) from being used in stats.facet.
> two immediately obvious problems...
> 1) in 3.5 the stats component is checking if isTokenzed() is true for the field type (which is probably wise) but regardless of the precisionStep used, TrieField.isTokenized is hardcoded to return true
> 2) the 3.5 stats faceting will fail if the FieldType is multivalued - it doesn't check if the SchemaField is configured to be single valued (overriding the FieldType)
> so even if a user has something like this in their schema...
> {code}
> <fieldType name="long" class="solr.TrieLongField" precisionStep="0" omitNorms="true" />
> <field name="ts" type="long" indexed="true" stored="true" required="true" multiValued="false" />
> {code}
> ...stats.facet will not work.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org