David Smiley created SOLR-9404:
----------------------------------
Summary: JSON FacetFieldProcessor subclass rename/moves
Key: SOLR-9404
URL: https://issues.apache.org/jira/browse/SOLR-9404
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Components: Facet Module
Reporter: David Smiley
Assignee: David Smiley
... spinoff of my comment on
https://issues.apache.org/jira/browse/SOLR-9142?focusedCommentId=15408535&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15408535
...
* taste: the fact that some FFP's are declared within FacetField.java and some
are top-level is bad IMO; they should all be top-level once any subclasses
start becoming so.
* FFPFCBase: This is basically the base class for _array based_ accumulator
implementations -- i.e. direct slot/value accumulators. I suggest rename to
FFPArray. It can handle terms (strings), not numbers directly but those
encoded as terms, and multi-valued capable.
* FFPDV: Rename to FFPArrayDV: accesses terms from DocValues
* FFPUIF: Rename to FFPArrayUIF: accesses terms via UIF, kind of a pseudo-DV
* FFPNumeric: Rename to FFPHashDV: Now currently this thing is expressly for
single-valued numeric DocValues. _In SOLR-9142 (not here) I intend to make
this generic to handle terms by global ordinal._
* FFPStream: Rename to FFPEnumTerms: This does enumeration (not hash or array
accumulation), and it gets data from Terms. Perhaps Stream could also go in
the name but I think Enum is more pertinent. One day once we have PointValues
in Solr, we might add a FFPEnumPoints. Note that such a thing wouldn't stream,
since that API uses a callback API instead of an iterator style.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
