[SOLR-9809] TrieField.createFields produces useless IndexableField instances when field is stored=false indexed=false

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Assignee: Unassigned
• Reporter: Chris M. Hostetter
• Created: 29/Nov/16 00:48
• Updated: 08/Jun/19 15:29

Description

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.

Issue Links

• relates to: SOLR-5944 Support updates of numeric DocValues