e.org
Subject: Re: 2 Level grouping (solr 5.5.3)
On 11/20/2018 9:45 PM, Ian Caldwell wrote:
>
> Yes the bugs were in the std code JIRS created.
>
> https://issues.apache.org/jira/browse/SOLR-13004
>
> https://issues.apache.org/jira/browse/SOLR-13005
>
Can you attach patches
sharing, Ian. Perhaps one day Solr will have a 3rd party plugin
registry of sorts where you could publish it.
It wasn't clear if the bugs you listed were in your plugin or in Lucene/Solr.
If the latter, and if you have time, please file JIRA issue(s).
On Sun, Nov 18, 2018 at 10:25 PM Ian Cal
s that we needed for our system. Along
the way I found a couple of bugs that I fixed in this code (1. Integer overflow
in holding the total record count & 2. Not searching all shards when performing
the second phase of the query(get all records within a group)).
Ian Caldwell
National
?Is there
a technical difficulty or any other reason?
380382...@qq.com<mailto:380382...@qq.com>
From: Ian Caldwell<mailto:icaldw...@nla.gov.au>
Date: 2017-04-07 10:33
To: 'dev@lucene.apache.org'<mailto:dev@lucene.apache.org>
Subject: RE:
and shard2. so the group.ngroup always bigger than the realy
number?
380382...@qq.com<mailto:380382...@qq.com>
From: Ian Caldwell<mailto:icaldw...@nla.gov.au>
Date: 2017-04-07 09:32
To: 'dev@lucene.apache.org'<mailto:dev@lucene.apache.org&g
I think the this happens because the First Pass gets the top nGroups and holds
the shards that they came from,
then for the second pass it is only searching the shards that contributed to
the list instead of searching all shards.
So if searching for the top 10 groups a shard may have data from
