It's been a while since I don't check that, @jason do you mean that: 1) results grouping happens after shard aggregations 2) field collapsing happens before shard aggregations
Literally shooting in the dark, just reading the email, with zero time to investigate, but in general, I'm in favour of deprecating results grouping,I've always been using it over results grouping for a while. But we need to make sure that we have a decent feature parity (not exact feature parity though). Cheers -------------------------- *Alessandro Benedetti* Director @ Sease Ltd. *Apache Lucene/Solr Committer* *Apache Solr PMC Member* e-mail: a.benede...@sease.io *Sease* - Information Retrieval Applied Consulting | Training | Open Source Website: Sease.io <http://sease.io/> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter <https://twitter.com/seaseltd> | Youtube <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github <https://github.com/seaseltd> On Fri, 10 Jan 2025 at 12:21, 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 > >
