Github user merrimanr commented on the issue:
https://github.com/apache/metron/pull/995
I did some additional testing and here are my notes. I've attempted to
compile a list of all the proposed solutions and their outcomes.
> checking the type for isPolyField()
This method is not available in the Solrj client library and would require
adding a dependency on solr-core which I don't think we want to do. Compiling
a list of field type to polyfield mappings would need to be something we do
outside of runtime and maintain across Solr upgrades. I did this and found
that out of the field types include with Solr 6.6, these are polyfields:
- CurrencyField
- DateRangeField
- LatLonPointSpatialField
- LatLonType
- PointType
- SpatialRecursivePrefixTreeFieldType
I also added any types not currently defined in our schemas and indexed
sample data. Only LatLonType and PointType resulted in expanded fields.
> migrate to solr.LatLonPointSpatialField and maintain separate schemas
The solr.LatLonPointSpatialField type worked without issue in Solr 6.6 as
expected. I installed a separate 5.5 instance and indexed the same data.
There is no error thrown but the data ends up looking like this in the index:
```
{
"enrichments.geo.ip_dst_addr.location_point_0_coordinate": [
"34.0438",
"34.0438"
],
"enrichments.geo.ip_dst_addr.location_point_1_coordinate": [
"-118.2512",
"-118.2512"
],
"enrichments.geo.ip_dst_addr.location_point": "34.0438,-118.2512"
}
```
That does not look correct to me. If this were to be acceptable what would
our approach be for testing and maintaining separate schemas for different
versions? Our code does not compile with version 5.5.
> disabling docValues for the spatial field
The docValues setting is already disabled in our schemas.
> using LukeRequest to get field type information
This does not handle the case of dynamic fields so we will need to come up
with a strategy to map dynamic fields to the field types we care about. I
think we may need to do this regardless of which approach we decide on. It
will be necessary to match dynamic field types to fields that are actually
present in a document.
Am I missing any solutions that have been proposed? Let me know I will
investigate.
I also looked into the date field issue I noticed. Turns out I was wrong
and this was actually a result of a copyField being defined. This is another
case we will need to handle. If a field is a copyField you cannot reindex that
field or you will get an error.
---