[
https://issues.apache.org/jira/browse/SOLR-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643181#comment-14643181
]
ASF GitHub Bot commented on SOLR-7835:
--------------------------------------
GitHub user grossws opened a pull request:
https://github.com/apache/lucene-solr/pull/197
Incorrect absent docValues check
`lucene.document.FieldType#docValuesType()` call always return non-null
result
which is protected by setter and copy constructor.
This method is used in `solr.schema.FieldType#createFields(...)` to enforce
valid docValues type
for field with `docValues="true"` in schema.
Current check is incorrect since it compares `docValuesType` to `null`
which is always false.
In case of incorrectly implemented Solr FieldType which overrides
`checkSchemaField(...)`
to allow docValues and doesn't override `createFields(...)` it leads to
buggy behavior:
user think that field use docValues (since it's set in schema.xml and solr
doesn't indicates
any error), but really UninvertingReader with fieldValuesCache is used for
faceting, grouping etc.
Test to demonstrate this issue is added to `DocValuesTest` class.
Fixes SOLR-7835.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/grossws/lucene-solr fix-dv-unsupported
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/lucene-solr/pull/197.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #197
----
commit 0a43d76a83ff00894c5cade02cf01ce7ec43f701
Author: Konstantin Gribov <[email protected]>
Date: 2015-07-08T12:54:33Z
Incorrect absent docValues check
`lucene.document.FieldType#docValuesType()` call always return non-null
result
which is protected by setter and copy constructor.
This method is used in `solr.schema.FieldType#createFields(...)` to enforce
valid docValues type
for field with `docValues="true"` in schema.
Current check is incorrect since it compares `docValuesType` to `null`
which is always false.
In case of incorrectly implemented Solr FieldType which overrides
`checkSchemaField(...)`
to allow docValues and doesn't override `createFields(...)` it leads to
buggy behavior:
user think that field use docValues (since it's set in schema.xml and solr
doesn't indicates
any error), but really UninvertingReader with fieldValuesCache is used for
faceting, grouping etc.
Test to demonstrate this issue is added to `DocValuesTest` class.
Fixes SOLR-7835.
----
> solr.schema.FieldType#createFields has incorrect check for absent docValues
> ---------------------------------------------------------------------------
>
> Key: SOLR-7835
> URL: https://issues.apache.org/jira/browse/SOLR-7835
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
> Affects Versions: 5.2.1
> Reporter: Konstantin Gribov
> Priority: Minor
>
> {{lucene.document.FieldType#docValuesType()}} call always return non-null
> result which is protected by setter and copy constructor.
> This method is used in {{solr.schema.FieldType#createFields(...)}} to enforce
> valid docValues type for field with {{docValues="true"}} in schema.
> Current check is incorrect since it compares {{docValuesType}} to {{null}}
> which is always false.
> In case of incorrectly implemented Solr FieldType which overrides
> {{checkSchemaField(...)}} to allow docValues and doesn't override
> {{createFields(...)}} it leads to buggy behavior: user thinks that field use
> docValues (since it's set in schema.xml and solr doesn't indicates any
> error), but really {{UninvertingReader}} with {{fieldValuesCache}} is used
> for faceting, grouping etc.
> This issue is only present when user creates his own
> {{solr.schema.FieldType}} implementation because Solr FieldTypes which don't
> support docValues do not override {{checkSchemaField(...)}} method.
> I will push pull request with patch and test case in several minutes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
