lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] Commented: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes
Date Sun, 27 Dec 2009 22:12:29 GMT


Yonik Seeley commented on SOLR-1688:

bq. Then why isn't ValueSource and FieldCacheSource in the o.a.solr.schema package?

Historical - ValueSource came from function query... but it's become(ing) more useful and
Rhetorical question: should all implementations of Map be in the java.util package? 

bq. And more so, why is it OK for some and not OK for others

Think of it this way - some FieldType's may implement their getValueSource with a publicly
defined ValueSource and others may not.  It's not the case that for a given FooFieldType that
there should be a publicly usable FooValueSource.  There should never be any guarantee that
a specific FieldType use a specific implementation of a ValueSource.  The only guarantee should
be that it work.  And if that's the case, one should ask why all these value sources should
be public?

> Inner class FieldCacheSources should be refactored into their own classes
> -------------------------------------------------------------------------
>                 Key: SOLR-1688
>                 URL:
>             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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message