[ 
https://issues.apache.org/jira/browse/SOLR-12350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl updated SOLR-12350:
-------------------------------
    Fix Version/s:     (was: 7.4)
                   7.5

> Do not use docValues as stored for _str (copy)fields in _default configset
> --------------------------------------------------------------------------
>
>                 Key: SOLR-12350
>                 URL: https://issues.apache.org/jira/browse/SOLR-12350
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Data-driven Schema
>            Reporter: Jan Høydahl
>            Assignee: Jan Høydahl
>            Priority: Major
>             Fix For: master (8.0), 7.5
>
>         Attachments: SOLR-12350.patch, SOLR-12350.patch
>
>
> When improving data-driven mode in SOLR-9526 we discussed back and forth 
> whether to set {{useDocValuesAsStored}} for the {{*_str}} copy of text 
> fields. This dynamic field is currently defined as
> {code:xml}
> <dynamicField name="*_str" type="strings" stored="false" docValues="true" 
> indexed="false" />{code}
> Having lived with the current setting since 7.0, I think it is too noisy to 
> return all the _str fields since this is redundant content from the analysed 
> original field. Thus I propose to do as [~hossman] initially suggested, and 
> explicitly set it to false starting from 7.4:
> {code:xml}
> <dynamicField name="*_str" type="strings" stored="false" indexed="false" 
> docValues="true" useDocValuesAsStored="false" />
> {code}
> Note that this does not change how things are stored, only whether to display 
> these by default. The {{*_str}} fields will still be available for sorting, 
> faceting etc.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to