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.


---

Reply via email to