[
https://issues.apache.org/jira/browse/SOLR-10237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900464#comment-15900464
]
Tomás Fernández Löbbe commented on SOLR-10237:
----------------------------------------------
bq. I think this is the path forward.
I'll upload a patch shortly
bq. I'm wondering if we may want to deprecate/remove the singular
{{SchemaField.createField}} and simply have all field types do their logic in
one method {{createFields}}
I think that would make sense, at least the reason for which both were created
separately is not being used:
{code:java}
/**
* If true, then use {@link #createFields(Object, float)}, else use {@link
#createField} to save an extra allocation
* @return true if this field is a poly field
*/
public boolean isPolyField(){
return type.isPolyField();
}
{code}
There are a couple of calls to {{createField(...)}} that should be replaced
though, I didn't look into them in detail.
bq. Perhaps further, it might accept the Lucene {{Document}} as a destination
to thus avoid some needless {{Field[]}} creation
Maybe... I'm not totally sold. I think there are valid use cases for wanting to
modify the returned list before adding it to the {{Document}}
bq. I'm bumping into this a bit as I contemplate a TextField that can
optionally put it's stored value embedded in a separate (compressed)
BinaryDocValuesField – SOLR-10117.
Not sure I follow, how would this refactor help?
> Poly-Fields should error if subfield has docValues=true
> -------------------------------------------------------
>
> Key: SOLR-10237
> URL: https://issues.apache.org/jira/browse/SOLR-10237
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Tomás Fernández Löbbe
> Priority: Minor
> Attachments: SOLR-10237.patch
>
>
> DocValues aren’t really supported in poly-fields at this point, but they
> don’t complain if the schema definition of the subfield has docValues=true.
> This leaves the index in an inconsistent state, since the SchemaField has
> docValues=true but there are no DV for the field.
> Since this breaks compatibility, I think we should just emit a warning unless
> the subfield is an instance of {{PointType}}. With
> {{\[Int/Long/Float/Double/Date\]PointType}} subfields, this is particularly
> important, since they use {{IndexOrDocValuesQuery}}, that would return
> incorrect results.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
