[
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414857#comment-13414857
]
Chris Male commented on LUCENE-4167:
------------------------------------
Okay I'm going to try to find some middle ground here so we can move forward:
bq. Here's an idea: what if makeQuery() goes away? Why is it needed when it can
be constructed by a client quite simply like it is now:
+1. The score for spatial Documents seems like it could be calculated from a
variety of factors. One of those factors could be distance, another could be
overlap percentage. So using ValueSource with FunctionQuery seems to give us
maximum flexibility.
We can maybe move the makeQuery as you defined to a utility class (maybe with
the stored-field stuff) which focuses on providing an easy API for the 90% of
use cases.
Can we rename makeValueSource to makeDistanceValueSource so that it is clearer
what it does? I'm not really sure how best to handle ValueSources calculating
scores from other factors just yet so lets just put that on the backburner.
This leaves us with only needing makeXXXFilter for each Operation. I like
Ryan's suggestion of using the XXXFilterBuilder interfaces. It doesn't seem
like a huge overhead for Strategys that share logic between operations to have
to implement a method and call another, 3 lines at the most. Reasonable?
bq. The command pattern isn't a hack, I find it rather appropriate in this
case, and I remember thinking it was a brilliant move by Ryan to have used it
when I first saw it in Strategy for the first time. The distance precision is
kind of a "hint" that is optional. On the other hand, the shape & operation are
fundamental
I can see situations whereby we do have a mix of required parameters (such as
Shape, field name) and some that are optional and only apply to certain
Strategys. So how about we rename SpatialArgs to SpatialCommand? and we
document that we will treat changes to SpatialCommand like we would to the
Strategy APIs, i.e. we won't be removing / changing things without
consideration. Having the Command also means we can handle bw compat more I
guess.
> Remove the use of SpatialOperation
> ----------------------------------
>
> Key: LUCENE-4167
> URL: https://issues.apache.org/jira/browse/LUCENE-4167
> Project: Lucene - Java
> Issue Type: Bug
> Components: modules/spatial
> Reporter: Chris Male
> Attachments: LUCENE-4167.patch,
> LUCENE-4167_migrate_com_spatial4j_core_query_to_Lucene_spatial.patch,
> LUCENE-4167_migrate_com_spatial4j_core_query_to_Lucene_spatial.patch
>
>
> Looking at the code in TwoDoublesStrategy I noticed
> SpatialOperations.BBoxWithin vs isWithin which confused me. Looking over the
> other Strategys I see that really only isWithin and Intersects is supported.
> Only TwoDoublesStrategy supports IsDisjointTo. The remainder of
> SpatialOperations are not supported.
> I don't think we should use SpatialOperation as this stage since it is not
> clear what Operations are supported by what Strategys, many Operations are
> not supported, and the code for handling the Operations is usually the same.
> We can spin off the code for TwoDoublesStrategy's IsDisjointTo support into a
> different Strategy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
