[
https://issues.apache.org/jira/browse/SOLR-10237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900215#comment-15900215
]
Tomás Fernández Löbbe commented on SOLR-10237:
----------------------------------------------
bq. {{solr.PointType}} (an x,y generic spatial field) supports DocValues in its
coordinate fields so they can be used in ValueSource/"function queries"
I don't believe it does. When a PointType field is created it calls
{{SchemaField.createField(...)}} on it coordinates, instead of
{{SchemaField.createField**s**(...)}}. The first one of those only creates the
"Index field", and doesn't create the DocValues field:
{code:java}
@Override
public List<IndexableField> createFields(SchemaField field, Object value,
float boost) {
String externalVal = value.toString();
String[] point = parseCommaSeparatedList(externalVal, dimension);
// TODO: this doesn't currently support polyFields as sub-field types
List<IndexableField> f = new ArrayList<>(dimension+1);
if (field.indexed()) {
for (int i=0; i<dimension; i++) {
SchemaField sf = subField(field, i, schema);
f.add(sf.createField(point[i], sf.indexed() && !sf.omitNorms() ? boost
: 1f));
}
}
if (field.stored()) {
String storedVal = externalVal; // normalize or not?
f.add(createField(field.getName(), storedVal, StoredField.TYPE, 1f));
}
return f;
}
{code}
Another option is to start supporting DV in the coordinates by creating the DV
fields when requested, they could be used as you said when ValueSource is
needed, probably inheriting the configuration (docValues=true/false) from the
PointType field?
> 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]
