[
https://issues.apache.org/jira/browse/SOLR-12963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676193#comment-16676193
]
Tim Underwood commented on SOLR-12963:
--------------------------------------
{quote} * should we explicitly "fail" if a user requested {{method}} doesn't
match the field props?{quote}
Yes please. I find it very confusing/frustrating when I explicitly request a
faceting method that then does not get used for whatever reason. The JSON
facets ({{FacetField.createFacetProcessor}}) seem especially picky about how it
chooses its faceting method. I think a Point field with docValues=true can
only use FacetFieldProcessorByHashDV. However Solr will let me request any
faceting method I want and silently ignore it. (Shameless plug for SOLR-12880
which will at least tell you which facet processor was used).
> change default for 'uninvertible' to 'false' (dependent on new schema
> 'version')
> --------------------------------------------------------------------------------
>
> Key: SOLR-12963
> URL: https://issues.apache.org/jira/browse/SOLR-12963
> Project: Solr
> Issue Type: Sub-task
> Reporter: Hoss Man
> Priority: Major
> Attachments: SOLR-12963.patch
>
>
> We should consider changing the default behavior of the {{uninvertible}}
> field option to be dependnt on the schema {{version}} property, such that
> moving forward the fields/fieldtypes will default to {{uninvertible ==
> false}} unless an explicit {{uninvertible=true}} is specified by the user.
> There are a lot of considerations regarding the existing behavior of
> functionality (like faceting) when the (effective) value of {{uninvertible}}
> is false because we move forward with changing this in a way that could
> suprise/confuse new users or existing users w/ long heald expectations that
> certain behavior would just "work" w/o understanding that was because of
> FieldCache/uninversion.
> See parent issue for more background/discussion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
