Umut Saribiyik created SOLR-18006:
-------------------------------------

             Summary: Possible issue with distance sorting on 
LatLonPointSpatialField in Solr 9.9 / 9.10
                 Key: SOLR-18006
                 URL: https://issues.apache.org/jira/browse/SOLR-18006
             Project: Solr
          Issue Type: Bug
          Components: search
    Affects Versions: 9.10, 9.9
         Environment: * Solr 9.9.0 (official Docker image)

 * Solr 9.8.0 (for comparison – works as expected)

 * Field type: {{org.apache.solr.schema.LatLonPointSpatialField}}
            Reporter: Umut Saribiyik
         Attachments: solr-1.log

*Summary*
Regression in 9.9 and 9.10.0: distance sort ({{{}geodist() 
{color:#de350b}*desc*{color}{}}}) on {{LatLonPointSpatialField}} throws 
exception (works in 9.8)

*Description*
After upgrading our search application from Solr 9.8 to 9.9, our distance-based 
sorting stopped working. Investigation showed that sorting by distance on a 
{{LatLonPointSpatialField}} now causes an exception. No configuration changes 
were made on the Solr side apart from the version upgrade.

To verify, I started a clean Solr 9.9 Cloud environment using the official Solr 
Docker image and was able to reproduce the issue with a minimal setup.

I’ve already reported this on the Solr User mailing list:
[https://lists.apache.org/thread/x4q83wnbqkp78vt39tr0dtn1rxjy4vfy]
----
*Environment*
 * Solr 9.9.0 (official Docker image)

 * Solr 9.8.0 (for comparison – works as expected)

 * Field type: {{org.apache.solr.schema.LatLonPointSpatialField}}

----
*Field definition*

The issue occurs with a field of type {{{}LatLonPointSpatialField{}}}. In my 
test case I used the default wildcard-based point field {{{}*_p{}}}, e.g. 
{{{}location_p{}}}.
----
*Query*
q=*:* 
fq=\{!geofilt} 
pt=48.11308880280511,11.622015740056845 
d=10 
sfield=location 
sort=geodist() desc
 
Here, {{location}} (or {{location_p}} in the minimal example) is a 
{{{}LatLonPointSpatialField{}}}.

The problem only occurs when sorting in *descending* order: {{{}sort=geodist() 
desc{}}}.
Sorting ascending ({{{}sort=geodist() asc{}}}) works as expected.

When using {{{}sort=geodist() desc{}}}, Solr throws an exception (see 
[^solr.log]).
----
*Steps to Reproduce*
 # *Start Solr 9.9 via Docker*
docker run -d -v "$PWD/solrdata:/var/solr" -p 8983:8983 --name my_solr 
solr:9.9.0 solr-precreate gettingstarted
 
 
 # *Index sample documents with a {{LatLonPointSpatialField}}*

The field {{location_p}} is a point field (from the wildcard {{{}*_p{}}}):
{
    "id": "pt-001",
    "location_p": "48.106651,11.628476"
  },
  \{
    "id": "pt-002",
    "location_p": "48.113089,11.622016"
  },
  \{
    "id": "pt-003",
    "location_p": "48.137154,11.576124"
  },
  \{
    "id": "pt-004",
    "location_p": "48.135125,11.581981"
  },
  \{
    "id": "pt-005",
    "location_p": "48.121,11.612"
  },
  \{
    "id": "pt-006",
    "location_p": "48.09,11.64"
  }
 
 
 # *Run the query that triggers the issue*
http://localhost:8983/solr/gettingstarted/select?q=*:*&sfield=location_p&fq=\{!geofilt}&pt=48.11308880280511,11.622015740056845&d=5000&sort=geodist()
 desc
 
 

----
*Workaround*

As a temporary workaround, the following query works without error:

 
{code:java}
q={!geofilt}  // Workaround
fq={!geofilt}
pt=48.11308880280511,11.622015740056845
d=10
sfield=location
sort=geodist(){code}
 

So using '\{!geofilt}' as the main query ('q') and sorting by 'geodist()' 
(ascending) avoids the exception. The issue is specifically related to 
'sort=geodist() desc' on 'LatLonPointSpatialField' in Solr 9.9.


*Expected Behavior*
Results should be returned successfully, sorted by distance in descending order.

*Actual Behavior*
Solr returns an exception when using {{sort=geodist() desc}} on a 
{{LatLonPointSpatialField}} in Solr 9.9. The same configuration and queries 
work correctly in Solr 9.8.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to