[
https://issues.apache.org/jira/browse/SOLR-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16459719#comment-16459719
]
Dr Oleg Savrasov commented on SOLR-8998:
----------------------------------------
I like the idea. Usage of proposed uniqueBlock(_root_) aggregation looks very
similar to unique(_root_) workaround. But the implementation avoids
accumulating FixedBitSet for each slot. The only thing I worry about is found
hack with limit:-1. I believe uniqueBlock should perform much better with it,
but I don't see any way to use it by default without modifying main facet
machinery. Shall we somehow document that it's recommended to use uniqueBlock
aggregation with limit:-1 facet parameter?
> JSON Facet API child roll-ups
> -----------------------------
>
> Key: SOLR-8998
> URL: https://issues.apache.org/jira/browse/SOLR-8998
> Project: Solr
> Issue Type: New Feature
> Components: Facet Module
> Reporter: Yonik Seeley
> Priority: Major
> Attachments: SOLR-8998.patch, SOLR-8998.patch, SOLR-8998.patch,
> SOLR_8998.patch, SOLR_8998.patch, SOLR_8998.patch
>
>
> The JSON Facet API currently has the ability to map between parents and
> children ( see http://yonik.com/solr-nested-objects/ )
> This issue is about adding a true rollup ability where parents would take on
> derived values from their children. The most important part (and the most
> difficult part) will be the external API.
> [~mkhludnev] says
> {quote}
> The bottom line is to introduce {{uniqueBlock(\_root_)}} aggregation, which
> is supposed to be faster than {{unique(\_root_)}} and purposed for blocked
> index only. For now it it supports singlevalue string fields, docValues
> usually make sense.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
