Indeed, Result Grouping supports distributed search. I see this documented in its ref guide page (at the bottom), and also tested -- TestDistributedGrouping. I wish Result Grouping functionality was better separated. I suppose QueryComponent isn't *too* bad, because of the method based organization. SimpleFacets has some complexity too.
On Fri, Jan 10, 2025 at 7:21 AM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > I'm not against deprecating "Result Grouping" per-se, but it has one > huge advantage over Collapse/Expand: Result Grouping is the only > approach that supports multi-shard. > > Should we come up with a plan for that and other gaps before we > deprecate Result Grouping? Deprecating the feature before there's > even a path to removing it might spook users unnecessarily for whom > "Result Grouping" is the only legitimate option. > > Best, > > Jason > > > On Thu, Jan 9, 2025 at 4:40 PM David Smiley <dsmi...@apache.org> wrote: > > > > Solr has supported Result Grouping[1] for a long time but has mostly been > > duplicative with Collapse & Expand[2]. At the start of the RG docs, > > there's this notice which I wrote many (10?) years ago: > > > > > Prefer Collapse & Expand instead > > > Solr’s Collapse and Expand Results feature is newer and mostly overlaps > > with Result Grouping. > > > There are features unique to both, and they have different performance > > characteristics. > > > That said, in most cases Collapse and Expand is preferable to Result > > Grouping. > > > > I wrote that note into the guide to shift our users to the better > > alternative so that we could someday more formally actually deprecate > then > > remove Result Grouping. > > > > I was motivated by a strong distaste, really disgust, at the complexity > > that it had, starting with QueryComponent (ground zero for that > complexity) > > but leaks to many places elsewhere, which is the real indication of a > > complex thing. QC got a little organizational love (thanks Christine) > once > > but it doesn't change my opinion. Collapse & Expand then came along and > > showed an alternative that is superior from a maintenance / design point > of > > view (thanks Joel), and typically performs better too. A colleague > noticed > > the same complexity and actually ripped it out of our fork, touching some > > 78 files in the process, including removing a dependency on > > lucene-grouping. I'd be happy to post a draft PR of what that looks like > > if it would help motivate us to pursue this. > > > > After polling our users for understanding why they have not moved on, I'd > > like to take the next step of deprecating it along with a log message > that > > would occur on first use via our DeprecationLog mechanism. It's > premature > > to discuss deleting the code. I'm worried that there's functionality > that > > is used that has no equivalent. > > > > [1] > > > https://solr.apache.org/guide/solr/latest/query-guide/result-grouping.html > > [2] > > > https://solr.apache.org/guide/solr/latest/query-guide/collapse-and-expand-results.html > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
