Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/995
@mmiklavc That sounds right, yes. For returning dynamic fields (at least on
the known problematic fields), I don't think it's pretty much ever
advantageous. At most it avoids a split on the LatLon result to pull out just
latitude or longitude. I think the newer version of geospatial,
LatLonPointSpatialField, is in the list not problematic list, so presumably
this realization was made and it's handled similar to others.
As an aside, looking through the javadocs, there's this remark on
PointFields
>FieldCache is not supported for PointFields, so sorting, faceting, etc on
these fields require the use of docValues="true" in the schema.
Even though we don't use PointField in our schemas, we may still want to
make that note in our docs. Seems like a fairly important caveat.
We could also potentially, based on
https://lucene.apache.org/solr/guide/6_6/docvalues.html#DocValues-RetrievingDocValuesDuringSearch,
set `useDocValuesAsStored="false"`, which might sidestep this problem
entirely. The catch is I think there's a whole set of considerations regarding
performance and querying that I do not have the expertise to assess.
@merrimanr Are there any circumstances where we'd want copy fields? It
seems like we could just direct users to make a copy of the field in Metron and
just index the copy fields directly. The main concern would be if we're able to
manage globs in there, but even if we don't it doesn't seem like super
important functionality to support. At least at a glance; I may definitely be
missing use cases.
---
