[
https://issues.apache.org/jira/browse/SOLR-12325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023923#comment-17023923
]
Mikhail Khludnev commented on SOLR-12325:
-----------------------------------------
[~munendrasn] thanks for your feedback. I think it's worth to have tests
covering absent fields, values, no matches and so one.
I don't share concern about introducing new aggregation by suffixing existing
one. I feel like proposal with introducing first arg enum is inconvenient for
users, for example {{query}} enum mimics to {{json}}.{{query, }}I'm afraid it
will just confuse users.
However, giving that {{FunctionQParser.parseNestedQuery()}} requires argument
start from {{{}} or {{$}}, we can recognize query case in:
{{uniqueBlock(\{!v=type_s:parent})}} and {{uniqueBlock(\{!v=$type_param})}}.
But it's not possible to distinguish {{uniqueBlock($field_or_q_param)}} nor
handle {{uniqueBlock(\{! v=type_s:parent}). }}How everyone thinks about it?{{
}}
> introduce uniqueBlockQuery(parent:true) aggregation for JSON Facet
> ------------------------------------------------------------------
>
> Key: SOLR-12325
> URL: https://issues.apache.org/jira/browse/SOLR-12325
> Project: Solr
> Issue Type: New Feature
> Components: Facet Module
> Reporter: Mikhail Khludnev
> Assignee: Mikhail Khludnev
> Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-12325.patch, SOLR-12325.patch, SOLR-12325.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> It might be faster twin for {{uniqueBlock(\_root_)}}. Please utilise buildin
> query parsing method, don't invent your own.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
