[ 
https://issues.apache.org/jira/browse/SOLR-18006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18042430#comment-18042430
 ] 

Umut Saribiyik commented on SOLR-18006:
---------------------------------------

I created a simple unit test (based on tag 9.9.0) to execute the same request 
at code level, and the test completes without throwing an exception.
For some reason, Solr behaves differently when the request is sent via the HTTP 
API endpoint compared to when it is executed from within the unit test code.


*schema-spatial-fix.xml*
{code:java}
...
<dynamicField name="*_p"  type="location" indexed="true" stored="true"/>
...
<fieldType name="location" class="solr.LatLonPointSpatialField"/>
...

{code}
 

*Test*
{code:java}
package org.apache.solr.search;

import org.apache.solr.SolrTestCaseJ4;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;


public class TestSolr4SpatialFix extends SolrTestCaseJ4 {

    @BeforeClass
    public static void beforeClass() throws Exception {
        initCore("solrconfig-basic.xml", "schema-spatial-fix.xml");
    }

    @Override
    @Before
    public void setUp() throws Exception {
        super.setUp();
        clearIndex();
        assertU(commit());
        setupDocs();
    }

    @Test
    public void testSortFix() throws Exception {

        assertJQ(
                req(
                        "q",
                        "*:*",
                        "pt",
                        "48.11308880280511,11.622015740056845",
                        "d",
                        "50000",
                        "fq",
                        "{!geofilt}",
                        "sort",
                        "geodist() desc",
                        "sfield",
                        "location_p"
                ),
                1e-3,
                "/response/docs/[0]/id=='3'",
                "/response/docs/[1]/id=='4'",
                "/response/docs/[2]/id=='6'",
                "/response/docs/[3]/id=='5'",
                "/response/docs/[4]/id=='1'",
                "/response/docs/[5]/id=='2'"
        );
    }

    private void setupDocs() {
        assertU(adoc("id", "1", "location_p", "48.106651,11.628476"));
        assertU(adoc("id", "2", "location_p", "48.113089,11.622016"));
        assertU(adoc("id", "3", "location_p", "48.137154,11.576124"));
        assertU(adoc("id", "4", "location_p", "48.135125,11.581981"));
        assertU(adoc("id", "5", "location_p", "48.121,11.612"));
        assertU(adoc("id", "6", "location_p", "48.09,11.64"));
        assertU(commit());
    }
}
  {code}

*Test results*

!image-2025-12-03-09-39-31-871.png!

Any idea why it behaves differently in these two cases?

> 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.9, 9.10
>         Environment: * Solr 9.9.0 (official Docker image)
>  * Solr 9.10.0 (official Docker image)
>  * Solr 9.8.0 (for comparison – works as expected)
>  * Field type: {{org.apache.solr.schema.LatLonPointSpatialField}}
>            Reporter: Umut Saribiyik
>            Priority: Blocker
>             Fix For: 10.0
>
>         Attachments: image-2025-12-03-09-37-48-929.png, 
> image-2025-12-03-09-39-31-871.png, solr-1.log
>
>
> *Summary*
> Regression in 9.9 and 9.10: 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]
>  
> ----
> *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*
> Like the example in the solr doc: 
> [https://solr.apache.org/guide/solr/latest/query-guide/spatial-search.html#geofilt]
> {code:java}
> q=*:* 
> fq={!geofilt} 
> pt=48.11308880280511,11.622015740056845 
> d=10 
> sfield=location 
> sort=geodist() desc{code}
>  
> 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 
> attached [^solr-1.log]).
> ----
> *Steps to Reproduce*
> *1.Start Solr 9.9 via Docker*
> {code:java}
> docker run -d -v "$PWD/solrdata:/var/solr" -p 8983:8983 --name my_solr 
> solr:9.9.0 solr-precreate gettingstarted{code}
>  
> *2. Index sample documents with a {{LatLonPointSpatialField}}*
> The field location_p is a point field (from the wildcard *_p):
> {code:java}
>   {
>     "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"
>   } {code}
>   
> *3. Run the query that triggers the issue*
> {code:java}
> http://localhost:8983/solr/gettingstarted/select?q=*:*&sfield=location_p&fq={!geofilt}&pt=48.11308880280511,11.622015740056845&d=5000&sort=geodist()
>  desc {code}
>  
> ----
> *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.
> *FYI – Production field type*
> In our production setup, the affected geo field is based on:
> {code:java}
> <fieldType name="location_jts" 
> class="solr.SpatialRecursivePrefixTreeFieldType" geo="true" 
> spatialContextFactory="JTS" ... /> {code}
> For this field type ({{{}solr.SpatialRecursivePrefixTreeFieldType{}}} with 
> {{{}spatialContextFactory="JTS"{}}}), the issue also occurs, and in this case 
> it affects both {{sort=geodist() asc}} and {{{}sort=geodist() desc{}}}.



--
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