[
https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794727#action_12794727
]
Yonik Seeley commented on SOLR-1688:
------------------------------------
bq. The troubling part is that some of these classes, e.g., DoubleFieldSource,
FloatFieldSource, are defined as outer, public classes
Perhaps they should not have been public either.
But at this point... why mess with it? "consistency"? People shouldn't be
grabbing or referencing specific implementations of ValueSource of field types
- that's why the field type as a getValueSource(). For the rare expert level
users creating their own FieldType implementations (and that should be a rare),
it shouldn't be an issue.
> Inner class FieldCacheSources should be refactored into their own classes
> -------------------------------------------------------------------------
>
> Key: SOLR-1688
> URL: https://issues.apache.org/jira/browse/SOLR-1688
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 1.4
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Fix For: 1.5
>
> Attachments: SOLR-1688.Mattmann.122609.patch.txt
>
>
> While working on SOLR-1586 I noticed that outside of class level access (or
> package level), you can't really reference FieldCacheSources that are defined
> inside of their FieldType constituents (e.g., in the case of StrFieldSource
> as defined in StrField). What's more troubling is that the
> FieldType/FieldCacheSources are defined in an inconsistent fashion: some are
> done as inner classes, e.g., StrFieldSource and SortableFloatFieldSource,
> while others are defined as individual classes (e.g., FloatFIeldSource). This
> patch will make them all consistent and define each FieldCacheSource as an
> outside class, present in o.a.solr.search.function.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
