You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Marius Grama (Jira)" <ji...@apache.org> on 2020/07/11 21:01:00 UTC
[jira] [Resolved] (LUCENE-9407) Change the visibility of
LatLonXQuery classes to public
[ https://issues.apache.org/jira/browse/LUCENE-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marius Grama resolved LUCENE-9407.
----------------------------------
Resolution: Won't Fix
> Change the visibility of LatLonXQuery classes to public
> --------------------------------------------------------
>
> Key: LUCENE-9407
> URL: https://issues.apache.org/jira/browse/LUCENE-9407
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Affects Versions: 8.5.2
> Reporter: Marius Grama
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h2. Problem description
>
> A few years ago the geospatial queries classes have been refactored to be package-private:
>
> {code:java}
> final class LatLonPointInPolygonQuery extends Query
> {code}
>
> I get that there must be a reason for making use of package-private constructors in the geospatial query classes, but I'm wondering whether it would hurt to leave the classes still public.
>
> Having the classes package-private means that they can't be used outside of the
>
>
> {{package org.apache.lucene.document;}}
>
> This is the PR in which the refactoring was made:
> [https://github.com/apache/lucene-solr/commit/2264600ffe4649abb0edbe7a6882ffc82f6e918b]
>
>
>
> h2. Background
> h3. Elasticsearch Percolator dealing with geospatial queries
> In the elasticsearch code (specifically over the percolator functionality) I have noticed that when using polygon queries at the moment there isn't possible to do a reversed search on the search queries index.
>
> This means that for all the geospatial queries are applied against the elasticsearch memory index in order to check for a percolation match.
>
> If the percolator deals with
>
> {{org.apache.lucene.document.LatLonPointInPolygonQuery}}
>
> then it should probably suffice making use of the
>
> {{org.apache.lucene.document.LatLonShapeBoundingBoxQuery}}
>
> for finding the search queries that have polygons containing the LatLonPoint of the location field of the document being percolated.
> h2. Proposed solution
>
> Increase the visibility of the LatLonXQuery classes to {{public}} so that they can
> be used in other packages (e.g. elasticsearch percolator code).
>
> *NOTE* that the constructors of the classes are still package-protected reason why the classes won't be able to be instantiated outside of their original package.
>
> In the elasticsearch percolator code I'd have to make use explicitly of the LatLonPointInPolygonQuery class (_instanceof_) when analyzing the search queries to be used in the percolation process:
>
> [https://github.com/elastic/elasticsearch/blob/master/modules/percolator/src/main/java/org/elasticsearch/percolator/QueryAnalyzer.java#L186]
>
> h3. Pull request
>
> [https://github.com/apache/lucene-solr/pull/1583]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org