[
https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794737#action_12794737
]
Chris A. Mattmann commented on SOLR-1688:
-----------------------------------------
{quote}
I'm against making all ValueSource classes public. Some of them will clearly be
implementations very specific to a FieldType, and those implementation details
shouldn't be exposed unless needed.
{quote}
I don't get this especially when you yourself said most of these classes don't
really have detailed implementations (which I can corroborate when I put the
patch together for this issue looking at the code). Also, there is at least one
other community request to do this, SOLR-1689, albeit for a few select
ValueSources.
{quote}
No, the implementation of FieldType.getValueSource() is up to that FieldType
and it can make perfect sense to be co-located (esp if it's an implementation
detail of the FieldType).
{quote}
Then why isn't ValueSource and FieldCacheSource in the o.a.solr.schema package?
And more so, why is it OK for some and not OK for others, especially when none
of the ValueSource implementation classes is greater than a few hundred lines
of code, if that?
> 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.
