[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org