Github user dsmiley commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/323#discussion_r173906040
--- Diff:
solr/core/src/java/org/apache/solr/search/SolrDocumentFetcher.java ---
@@ -486,16 +486,14 @@ private Object decodeDVField(int localId, LeafReader
leafReader, String fieldNam
case SORTED_NUMERIC:
final SortedNumericDocValues numericDv =
leafReader.getSortedNumericDocValues(fieldName);
if (numericDv != null && numericDv.advance(localId) == localId) {
- if (schemaField.getType() instanceof LatLonPointSpatialField) {
- long number = numericDv.nextValue();
- return ((LatLonPointSpatialField)
schemaField.getType()).geoValueToStringValue(number);
- }
final List<Object> outValues = new
ArrayList<>(numericDv.docValueCount());
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
