[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
