The mergeIds() method should be true if you are handling the merge of the documents from the shards. If you are merging custom analytics from an AnalyticsQuery only then you would return false. In your case, since you are de-duping documents you would need to return true.
There are two methods in the MergeStrategy that you need to implement if you need to merge docs based on fields other then the sort fields. This is tricky to implement though and requires significant understanding of Solr's internals. The method: QueryComponent.doFieldSortValues shows how Solr sends the sort fields to the aggregator node. You can send your own merge fields to the aggregator by implementing methods in the MergeStrategy. The methods you need to implement in the MergeStrategy if you need custom fields to do the merge are below: * handlesMergeFields must return true if the MergeStrategy * implements a custom handleMergeFields(ResponseBuilder rb, SolrIndexSearch searcher) * */ public boolean handlesMergeFields(); /** * Implement handleMergeFields(ResponseBuilder rb, SolrIndexSearch searcher) if * your merge strategy needs more complex data then the sort fields provide. * */ public void handleMergeFields(ResponseBuilder rb, SolrIndexSearcher searcher) throws IOException; Joel Bernstein http://joelsolr.blogspot.com/ On Fri, Aug 5, 2016 at 10:56 AM, tedsolr <tsm...@sciquest.com> wrote: > I don't see any field level data exposed in the SolrDocumentList I get from > shardResponse.getSolrResponse().getResponse().get("response"). I see the > unique ID field and value. Is that by design or am I being stupid? > > Separate but related question: the mergIds() method in the merge strategy > class - when TRUE the developer is taking responsibility for the document > merge, when FALSE it looks like the QueryComponent puts all the results in > a > sorted queue and removes the "extras" - right? When rows=3 each shard > returns 3 docs, but the user only wants 3 total not 3 per shard. So, if I > set mergeIds=FALSE I won't have to resort the docs, just eliminate the > dupes > somehow. > > > Joel Bernstein wrote > > Collapse will have dups unless you use the _route_ parameter to co-locate > > documents with the same group, onto the same shard. > > > > In you're scenario, co-locating docs sounds like it won't work because > you > > may have different grouping criteria. > > > > The doc counts would be inflated unless you sent all the documents from > > the > > shards to be merged and then de-duped them, which is how streaming > > operates. But streaming has the capability to do these types of > operations > > in parallel and the merge strategy does not. > > > > > > -- > View this message in context: http://lucene.472066.n3.nabble.com/Can-a- > MergeStrategy-filter-returned-docs-tp4290446p4290556.html > Sent from the Solr - User mailing list archive at Nabble.com. >
