[
https://issues.apache.org/jira/browse/SOLR-15833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17454722#comment-17454722
]
ASF subversion and git services commented on SOLR-15833:
--------------------------------------------------------
Commit 187fc9c1b0054d92f9c842cfe4b8d8cb2fbd5a4b in lucene-solr's branch
refs/heads/branch_8_11 from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=187fc9c ]
SOLR-15833 Spatial types should work with exists query (#2624)
Co-Authored-By: Houston Putman <hous...@apache.org>
> Exists query does not work for SRPT
> -----------------------------------
>
> Key: SOLR-15833
> URL: https://issues.apache.org/jira/browse/SOLR-15833
> Project: Solr
> Issue Type: Bug
> Affects Versions: 8.6.3
> Reporter: Mike Drob
> Assignee: Mike Drob
> Priority: Major
> Fix For: 9.0, 8.11.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> @@ -172,6 +173,8 @@ public class TestSolr4Spatial extends SolrTestCaseJ4 {
> checkHits(fieldName, "0,0", 100, DistanceUtils.EARTH_MEAN_RADIUS_KM,
> 0);//doesn't error
> }
> + @Test public void testExistsQuery() { assertQ(req("q", fieldName + ":*",
> "fl", "id," + fieldName)); }
> +
> private void checkHits(String fieldName, String pt, double distKM, double
> sphereRadius, int count, int ... docIds) throws ParseException {
> checkHits(fieldName, true, pt, distKM, sphereRadius, count, docIds);
> }
> {noformat}
> This test passes against 8.5.0 release and fails when running 8.6.3.
> I initially suspected SOLR-11746, but that doesn't line up with the release
> info, unless some of that revert/recommit stuff came in later.
> This error happens because the {{exists}} query for spatial types gets turned
> into a range query with inclusive null bounds, which then causes the bounding
> box parsing to fail. And generating the exception incidentally fails because
> we try to pass a null argument to String.contains!
> Some options for solving this:
> * See null bounds when creating our shape and return a new shape that matches
> everything
> * Go back to using a prefix query
> * Find some other extra "clever" data like norms that the field leaves around
> We might also need to check additional fields for this same behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
