You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Chris Male (JIRA)" <ji...@apache.org> on 2009/12/11 16:09:18 UTC
[jira] Created: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Abstract Spatial distance filtering process and supported field formats
-----------------------------------------------------------------------
Key: LUCENE-2152
URL: https://issues.apache.org/jira/browse/LUCENE-2152
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/spatial
Affects Versions: 3.1
Reporter: Chris Male
Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Posted by "Simon Willnauer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795282#action_12795282 ]
Simon Willnauer commented on LUCENE-2152:
-----------------------------------------
Chris, indeed this is a tricky one. One problem with arises related to the map used for distance caching is when you want to use spatial with a filter and sort in contrib/remote. At least in the current code (not your patch - haven't looked at it yet though) the sort instance is obtained from the filter and depends on the map instance filled by the filter. After serialization the instance disappears and sort doesn't work anymore on the remote side. if we could decouple the distance storage from the filter implementation we could also come up with a solution for the sorting problem like providing a remoteCollector that has any key value lookup function (internally) that can be used by the sort function to lookup the calculated values.
I personally would go one step further and introduce an exchangeable distance calculation function in the first step and a collector in the second. It is even possible to introduce a delegation approach like the following example:
{code}
DistanceFunction func = new MapCachingDistFunc(new DefaultDistanceFunc(new CustomFieldDecoder());
for docId in docs:
if func(docid, reader, point) <= dist:
bitSet.set(docid)
{code}
That way we could completely separate the problem into a function interface / abstract class and can provide several implementations. It would also be possible to solve our problem with sorting where we can pass a special RemoteDistanceFunction to both the sort and filter impl. I don't know how it would look like in the impl though.
Maybe we can even use this function interface in the customscorequery as well.
Just some random ideas....
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch
>
>
> Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
> The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Male updated LUCENE-2152:
-------------------------------
Attachment: LUCENE-2152.patch
Updated patch so that it uses Point rather than Point2D.
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152.patch, LUCENE-2152.patch
>
>
> Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
> The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795293#action_12795293 ]
Chris Male commented on LUCENE-2152:
------------------------------------
I agree that we need to decouple the sort from the Filter. My current patches don't do that well enough unfortunately so I want to address that.
I like what you are suggesting, but I think there are a couple of things to consider. The storage of the distances is not just for sorting sake, as you say its also needed in the CustomScoreQuery for boosting, and also for presentation of the results. Given that, I'm still sort of favouring separating the distance calculation function from the storage mechanism.
If we added a DistanceCollector abstraction, then we could create a Remote impl for the Collector, and we could create a distance function (which I refer to as GeoDistanceCalculator in one of my other patches) which uses an existing DistanceCollector as a cache.
We could also make a NoOpDistanceCollector for those who don't want to actually store anything, and a RangeDistanceCollector for collecting values in ranges (which could be a space saving optimization, and could also help with distance range faceting).
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch
>
>
> Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
> The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Male updated LUCENE-2152:
-------------------------------
Attachment: LUCENE-2152-alt.patch
Attaching a new patch based on the above discussion.
This patch introduces the interface DocumentDistanceSource, which provides a single place to retrieve the distances for documents. It uses the new PointDecoder interface (a simplified version of the LocationDataSet in the previous patches) and the GeoDistanceCalculators to determine the distance for a document.
It comes with 2 implementations, SimpleDocumentDistanceSource which does the calculations always and does not cache, and MapCachingDocumentDistanceSource, which does some simple map caching of distances.
By using a combination of these impls, its possible for the user to choose whether they want the calculated distances to be stored or not. It also moves the storage out from the Filter, returning the filter to a more stateless impl.
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152-alt.patch, LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch
>
>
> Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
> The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795300#action_12795300 ]
Chris Male commented on LUCENE-2152:
------------------------------------
Ha, genius. I hadn't thought about the reuse between searches. That would make a huge difference in a situation where a user is changing their zoom on a map.
I'm with you now and agree whole heartedly with what you are suggesting. I really love the idea of having a single consistent way of retrieving a distance for a document, whether it be the Filter itself, the Sort, a Query, or some output mechanism. That would really hide away alot of the logic.
Would you then also put the task of loading/decoding the appropriate lat/lng info for Documents inside this distance function idea as well? (I think this was what you were suggesting a couple of posts ago).
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch
>
>
> Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
> The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801401#action_12801401 ]
Chris Male commented on LUCENE-2152:
------------------------------------
I am currently working on a new patch that will incorporate the ideas discussed here and will attach it shortly.
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch
>
>
> Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
> The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795083#action_12795083 ]
Chris Male commented on LUCENE-2152:
------------------------------------
One part of this implementation that I'm still wrestling with is the storage of the computed distances. Currently each docId computed-distance pair is stored in a Map which itself is stored in the DistanceFilter. This can then be retrieved through the SpatialFilter. This restricts the storage of the distances, which could be alot of values, to that chosen by the DistanceFilter. If someone preferred not to store the distances at all, for memory sake maybe, then they have no control over this. I'm thinking that it might be useful to have some sort of DistanceCollector abstraction through which users of the Filter can have greater control over how the distances are stored, if they are at all.
Any thoughts on this idea?
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch
>
>
> Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
> The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Male updated LUCENE-2152:
-------------------------------
Attachment: LUCENE-2152.patch
Added full deprecation annotations
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch
>
>
> Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
> The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Posted by "Chris Male (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Male updated LUCENE-2152:
-------------------------------
Attachment: LUCENE-2152.patch
Added patch that implements above behavior. Adds DistanceFilter interface with implementations for multi-threading and no-op, and LocationDataSet/Factory which is responsible for processing the different formats of data and converting it into a Point2D.
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152.patch
>
>
> Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
> The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering
process and supported field formats
Posted by "Simon Willnauer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795295#action_12795295 ]
Simon Willnauer commented on LUCENE-2152:
-----------------------------------------
bq. Given that, I'm still sort of favouring separating the distance calculation function from the storage mechanism.
The actual reasons why I proposed it that way are kind of special. Imagine you do a search 1mile around point X, the next search is 2 miles around point X. Yet for such a case you could simply wrap the function in another cache function using the already existing cache as second level cache. All the logic for that would be encapsulated in a simple function. None of the logic would be necessary in any of the implementations like CustomScoreQuery, Sort or Filter. Yet if you separate them into two interfaces (not necessarily the java interface) you would have to have some logic which checks if the values is already cached somewhere.
I'm not bound to this solution just throwing in randoms thoughts which could be useful for users to some extend. For me a distance is just a function and I don't care if it is cached or not. The logic which takes care on caching should be completely transparent IMO. If possible we should prevent calls inside the filter etc. like:
{code}
if(cached):
getFromCache()
else
getFromFunc()
{code}
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152.patch, LUCENE-2152.patch, LUCENE-2152.patch
>
>
> Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
> The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org