lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Updated] (LUCENE-4099) Remove generics from SpatialStrategy and remove SpatialFieldInfo
Date Tue, 03 Jul 2012 06:54:53 GMT


David Smiley updated LUCENE-4099:

    Attachment: LUCENE-4099_remove_SpatialFieldInfo_and_put_fieldName_into_Strategy_instead_of_methods.patch

Here is a patch.  This is a major change to the API.  The SpatialFieldInfo and its subclasses
are all gone, as well as the generics declarations on SpatialStrategy and SpatialStrategyTestCase.
 Essentially the related functionality was inlined into each strategy.  There is a little
duplication between TwoDoublesStrategy & BBoxStrategy to create a double and hold a configurable

I could have simply put the String field name into each method argument position which took
a fieldInfo, but instead I thought it nicer to put the field name into the Strategy instance
itself.  It is initialized as the 2nd constructor argument.  This does tie a Strategy instance
to a field, but I think that's fine and I'm quite happy with the overall affect.
> Remove generics from SpatialStrategy and remove SpatialFieldInfo
> ----------------------------------------------------------------
>                 Key: LUCENE-4099
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: modules/spatial
>            Reporter: Chris Male
>            Assignee: David Smiley
>            Priority: Minor
>         Attachments: LUCENE-4099_remove_SpatialFieldInfo_and_put_fieldName_into_Strategy_instead_of_methods.patch
> Same time ago I added SpatialFieldInfo as a way for SpatialStrategys to declare what
information they needed per request.  This meant that a Strategy could be used across multiple
requests.  However it doesn't really need to be that way any more, Strategies are light to
instantiate and the generics are just clumsy and annoying.
> Instead Strategies should just define what they need in their constructor. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message