Github user dsmiley commented on a diff in the pull request:
    --- Diff: 
solr/core/src/java/org/apache/solr/search/ ---
    @@ -486,16 +486,14 @@ private Object decodeDVField(int localId, LeafReader 
leafReader, String fieldNam
           case SORTED_NUMERIC:
             final SortedNumericDocValues numericDv = 
             if (numericDv != null && numericDv.advance(localId) == localId) {
    -          if (schemaField.getType() instanceof LatLonPointSpatialField) {
    -            long number = numericDv.nextValue();
    -            return ((LatLonPointSpatialField) 
    -          }
               final List<Object> outValues = new 
               for (int i = 0; i < numericDv.docValueCount(); i++) {
                 long number = numericDv.nextValue();
                 Object value = decodeNumberFromDV(schemaField, number, true);
                 // return immediately if the number is not decodable, hence 
won't return an empty list.
                 if (value == null) return null;
    +            // return the value as "lat, lon" if its not multi-valued
    --- End diff --
    I understand that internally the type is SORTED_NUMERIC either way.  But 
externally (from user's point of view) the visible behavior should be 
consistent with what would happen if the field were stored.  Please ensure this 
distinction is tested too (if it isn't already)


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to