[
https://issues.apache.org/jira/browse/SOLR-12880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16680376#comment-16680376
]
Tim Underwood commented on SOLR-12880:
--------------------------------------
{quote}Is that an indictment against all anonymous inner classes? Sounds like
it.
{quote}
I feel like maybe I hit a touchy subject? :) I can revert that piece of the
commit if needed. I see a mix of styles within the codebase so I don't know if
one style is preferred over another. Is there a preferred style?
In my experience whenever I start out with anonymous inner classes chances are
at some point I end up converting it to be non-anonymous since, for me, it
makes it easier to:
* Read Stack traces
* Understand memory profiling/debugging
* Track down class files for looking at the bytecode
As an example when I was recently profiling some of the faceting code I
personally found it to be more work to figure out what these refer to since
they are anonymous:
{code:java}
org.apache.solr.search.facet.FacetFieldProcessorByHashDV$5.collect(int)
org.apache.solr.search.facet.FacetFieldProcessorByHashDV$6.collect(int){code}
But that is just my personal opinion and experience. I'm more than happy to
follow whatever the preferred convention is.
{quote}+1 to getName(). I looked at your patch and see this method but nothing
overrides it... so it's kinda incomplete as-is; no?
{quote}
If the FacetHeatmapProcessor class becomes non-anonymous then the default
getName implementation should work. Unless you want something other than
"FacetHeatmapProcessor" as the name.
> Show the FacetProcessor class name instead of the FacetRequest in the JSON
> Facets debug-trace output
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-12880
> URL: https://issues.apache.org/jira/browse/SOLR-12880
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
> Affects Versions: 7.5
> Reporter: Tim Underwood
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the "facet-trace" debug output for the JSON facets the "processor" field
> current shows the class name of the FacetRequest implementation (e.g.
> FacetField, FacetQuery, FacetRange, etc.). It seems like this would be more
> useful if it showed the FacetProcessor class being used instead (e.g.
> FacetFieldProcessorByArrayDV, FacetFieldProcessorByHashDV,
> FacetQueryProcessor, FacetRangeProcessor, etc.)
> Example of how it works today:
> {noformat}
> "debug": {
> "facet-trace": {
> "processor": FacetQuery "elapse": 50 "query": null "domainSize": 3296
> "sub-facet": [{
> processor = FacetField,
> elapse = 18,
> field = partTypeId,
> limit = -1,
> domainSize = 3296,
> numBuckets = 392
> }, {
> processor = FacetField,
> elapse = 25,
> field = browseNodeId,
> limit = -1,
> domainSize = 3296,
> numBuckets = 535
> }]
> }
> }
> {noformat}
> This is what showing the FacetProcessor class name would show:
> {noformat}
> "debug": {
> "facet-trace": {
> "processor": FacetQueryProcessor "elapse": 77 "query": null "domainSize":
> 3442 "sub-facet": [{
> processor = FacetFieldProcessorByHashDV,
> elapse = 3,
> field = partTypeId,
> limit = -1,
> domainSize = 3442,
> numBuckets = 407
> }, {
> processor = FacetFieldProcessorByHashDV,
> elapse = 4,
> field = browseNodeId,
> limit = -1,
> domainSize = 3442,
> numBuckets = 553
> }]
> }
> }
> {noformat}
> Alternatively an additional debug field could be added with this information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
