[
https://issues.apache.org/jira/browse/SOLR-14007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17056132#comment-17056132
]
Munendra S N commented on SOLR-14007:
-------------------------------------
Thanks [~mkhl] for the review
Thanks [~jbernste] for the sharing your thoughts. Idea of table view looks
exciting. My idea was to provide similar view (key-value) with normal facet
response for percentile.
Thank you [~ysee...@gmail.com] for the detailed review.
{code:java}
Consistency should not be a goal since the Stats component should be deprecated
{code}
Huge +1 to deprecate stats component. Having multiple component to same
functionality is not required and also a maintenance hassle. I have been
working on this from past few months (but lesser speed than preferred). I have
created some tasks for the same and they are not exhaustive. Idea is not to fix
all of them but fix only those which makes sense. For example, returning
distinctValues could lead to potential OOM, there are other way to achieve the
say(terms component with limit) which need not have to be supported in json
facets. Similarly, avg on dates not sure of the usecase for finding avg on
date. If there is not such case, maybe failing rather than returning some date
or double value makes more sense
{code:java}
Regardless, what the Stats component currently does should really shouldn't
have much bearing on what solution we chose here.
{code}
Completely agree with this. Even with the current patch, when there are no
values unlike stats component not returning null for each percentile specified.
{code:java}
For percentile(), if the norm was a single argument, then representing the
response as a single value would be natural and multiple values would be an
extension (but an exception.
{code}
My understanding was always the other way around. I always thought median to
be case which could be supported via percentiles.
{code:java}
I also do question if this change actually makes anyones lives easier. The
vast majority of clients would know what they are asking for and hence the form
of answer they will get back?
{code}
I still think having consistent response format irrespective of number of
values specified, makes response processing cleaner without if-else checks.
The reason for going with NamedList(initial I built the patch with list in my
mind, still have it my local), is to make response self-contained as much
possible.
I have shared the reasoning behind the approach irrespective of namedList(would
prefer of self-containess) or list, would prefer to have consistent value type
in the response
Let me know if there are any suggestions
> Difference response format for percentile aggregation
> -----------------------------------------------------
>
> Key: SOLR-14007
> URL: https://issues.apache.org/jira/browse/SOLR-14007
> Project: Solr
> Issue Type: Sub-task
> Components: Facet Module
> Reporter: Munendra S N
> Assignee: Munendra S N
> Priority: Major
> Attachments: SOLR-14007.patch
>
>
> For percentile,
> In Stats component, the response format for percentile is {{NamedList}} but
> in JSON facet, the format is either array or single value depending on number
> of percentiles specified.
> Even if JSON percentile doesn't use NamedList, response format shouldn't
> change based on number of percentiles
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
