[
https://issues.apache.org/jira/browse/SOLR-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15703727#comment-15703727
]
Hoss Man commented on SOLR-9809:
--------------------------------
Backstory...
Working on SOLR-5944, i was really confused by a bit of code ishan in his patch
had & the associated explanation when i asked about it relating to the results
of calling {{field.getType().createFields(field, ...)}} in a code path where
we'd already asserted that the field was a single valued docValues only field...
{quote}
* if {{true==forInPlaceUpdate}} and {{createFields(...)}} returns anything that
is *not* a NumericDocValuesField (or returns more then one) shouldn't that trip
an assert or something? (ie: doesn't that mean this SchemaField isn't valid for
using with an in place update, and the code shouldn't have gotten this far?)
** {color:green}This is fine, since createFields() generates both NDV and non
NDV fields for an indexable field, and the intent is to drop the non NDV one.
Added a comment to this effect{color}
{quote}
...this response confused the hell out of me for a while because i couldn't
figure out any reason why createFields() should be returning "non NDV fields"
.... untill i noticed the way TrieField.createFields delegates to
TrieField.createField is different then every other docValue related FieldType:
it expects the result to always be non-null, which (unlike every other
FieldType) it always is.
> TrieField.createFields produces useless IndexableField instances when field
> is stored=false indexed=false
> ---------------------------------------------------------------------------------------------------------
>
> Key: SOLR-9809
> URL: https://issues.apache.org/jira/browse/SOLR-9809
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
>
> I'll provide more context in jira comment below, but important bit is this:
> * It seems that {{TrieField.createFields}} and/or {{TriedField.createField}}
> have a bug causing {{TrieField.createFields}} to return useless
> {{Legacy*Field}} instances when the field is _only_ using docValues (in
> addition to the important {{NumericDocValuesField}} instance which is also
> included in the list).
> * These useless IndexableField instances are passed along to the IndexWriter
> where they are ultimatley ignored because neither the stored nor index
> properties are set.
> * Other field types that support docValues (like StrField, BoolField and
> EnumField) don't seem to have this problem
> ** but EnumField may be including a useless {{null}} in the list? ... seems
> like a closely related bug.
> * root of the bug seems to be that in most classes, {{createField}} returns
> null if the field is indexed=false AND stored=false, but that's not true in
> {{TrieField}}
> ** subsequently {{createFields}} seems to to depend on {{createField}} not
> returning null, so it can reuse the already parsed numeric value
> * {{TrieField}} should be refactored to work the same as other fields that
> support docvalues, and not produce useless IndexableField objects -- or at
> the very least, to not pass them up to the caller
> * we should add some low level unit tests that loop over all the possible
> fieldTypes and sanity check that {{createFields}} returns an emptylist when
> appropriate (no docValues, no stored, no indexed)
> ** we should also probably update the key consumers of
> {{FieldType.createFields}} to assert the values in the list are non-null --
> wouldn't have caught this bug, but it might help catch similarly silly bugs
> in the future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
