[
https://issues.apache.org/jira/browse/LUCENE-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marius Grama updated LUCENE-9407:
---------------------------------
Description:
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]
was:
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)
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]
> 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: 10m
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
