Skip to content
This repository

Field Collapsing/Combining #256

Open
ppearcy opened this Issue July 13, 2010 · 225 comments

186 participants

Paul Pearcy

Ability to collapse on a field. For example, I want the most relevant result from all different report types. Or similarly, the most recent result of each report type. Or maybe, I want to de-dup on headline.

So, the sort order would dictate which one from the group is returned. Similar to what is discussed here:
http://blog.jteam.nl/2009/10/20/result-grouping-field-collapsing-with-solr/

From my understanding, it seems that in order for field collapsing to be efficient, the result set must be relatively small.

This is also referred to as "Combine" on some other search products.

Bruce Ritchie

Count this comment as a vote to have this feature added.

kwloafman

I could make good use of this feature. Go for it!

Maciej Dziardziel

+1 vote for that

ekalyoncu

yes it's really cool feature.

ekalyoncu

In SOLR, grouping is not supported for distributed search. If it's implemented, it can be big plus for ElasticSearch

Giorgio Vinci

The only workaround is to "group" the results on the client side is correct?
+1 For this. To have the logic on the server is what we need!

Jeroen Rosenberg

+1 This sounds really useful

Jayson Minard

This is probably a broader topic of collapsing (dropping dupes based on sort order although many times one field isn't enough to decide a good dedupe), or full rollups where you retain the individual documents within an aggregate replacement document ("5 books by this author").

There are fun issues with each, such as do you try to satisfy the requested window results? How does paging work when things are missing? Does the total document count get adjusted (but is still wrong as you don't know what other pages hold)? ...

Maciej Dziardziel

For me this should work like "select distinct" in sql - so i expect duplicates to be removed everywhere - including total document count, pagination and window result.

Jayson Minard

at that point, its a full group-by and in SQL you are getting aggregate values back in functions, and sometimes undefined if you ask for non-aggregate fields ... in the search engine how are the other fields besides the rollup key being treated? Is it a grouping into a master aggregate document listing all the children, or at least the fact that there are children such as what Endeca does? Of is it a deduping and the first one at highest relevancy wins even if many of the other fields differ outside of the key (you need compound keys then as deduping on a single field isn't enough to make that desirable)?

Paul Pearcy

Hey,
Just wanted to say that we are using our own poor man's version of this to satisfy some requirements by just requesting 10x the amount requested and collapsing down client side. Complete hack, but works 99% of the time.

We're now applying this and adding facets to it with a two phased approach. We first get the list of doc ids and then we pass them in as a term list and faceting on that query.

Was curious if there was any more efficient method of doing this?

Thanks,
Paul

David Martin

+1 vote for this issue too.
This is a really useful feature. Think about an e-commerce shop, indexing all sku. When looking at a product, a customer should have in his results list the products (and not the sku).

Till!
till commented May 10, 2011

subscribe

tfreitas

+1

vincenttheeten

plz don't make us switch to SOLR just for this feature
+1

Shay Banon
Owner
kimchy commented May 13, 2011

Note that solr does not implment it for a distributed search (as far as I know) and the implementation is problematic (my view).

Till!
till commented May 13, 2011

Are you referring to the "field collapse patch" floating around in their Jira? I haven't checked if that made it into a recent release so I don't know how up to date my info is, I just noticed that queries using "field collapse patch" are by magnitude slower than queries without.

Michael McCandless
Owner

Note that there is now (finally!) a new grouping module in Lucene -- see https://issues.apache.org/jira/browse/LUCENE-1421

It's been back-ported to 3.x, under lucene/contrib/grouping.

So in theory exposing this in ElasticSearch should be straightforward? (And, if it's not, I'd really like to know about that so we can fix it!).

There is some performance hit but not as bad as I had expected. See the 3 TermGroupXXX charts here: http://people.apache.org/~mikemccand/lucenebench -- it's ~ 2.3x-2.5X slower than the straight TermQuery, when grouping by a field with 100, 10K, 1M unique values (though, the sort and groupSort are relevance; maybe when sorting by other fields this is slower). This should also be the worst-case slowdown since TermQuery is such an "easy" query; queries which are "hard" and don't produce many results should see less net impact from the grouping overhead, I expect.

Shay Banon
Owner
kimchy commented May 19, 2011

Cool!, saw that a few days ago, will definitely have a look.

tfreitas

Hi, with the release of Lucene 3.2, one of its features are:
"A new grouping module, under lucene / contrib / grouping, enable search results to Be group by single-valued indexed field "
http://wiki.apache.org/lucene-java/ReleaseNote32

René Scheibe

+1

Aaron Binns

+1

0xPIT
0xPIT commented June 13, 2011

++1

Bernhard Bock
bbock commented June 14, 2011

+1

Stefan Lau
selaux commented June 14, 2011

+1

jmayr
jmayr commented June 14, 2011

+1

Michael McCandless
Owner

I'm also working on making it easy(ier) to distribute grouping, by adding static merge methods to TopDocs/TopGroups. Ie, each shard can run the 1st pass collector, send top groups back to front end, front end merges the top groups (SearchGroup.merge) and issues request to all shards to run 2nd pass collector, gets results back, merges with TopGroups.merge. This is all under https://issues.apache.org/jira/browse/LUCENE-3191

Alexander Reelsen
Owner

+1

steven casey

+1

any news on whether https://issues.apache.org/jira/browse/LUCENE-1421 as mentioned by mikemccand will work in elasticsearch?

Martin Sander

+1

SH-TE-JV
shtejv commented June 17, 2011

+1

Thomas Endres

+1

Christian Liebhardt

+1

letier
letier commented June 17, 2011

+1

Alberto Paro
aparo commented June 17, 2011

+1

Karthago

+1

Stefan Wolf
wolfs commented June 17, 2011

+1

wuan
wuan commented June 17, 2011

+1

Blagovest Dachev
dachev commented June 19, 2011

+1

Markus Schirp
mbj commented June 24, 2011

+1

Nick Campbell

+1

Olivier Favre
ofavre commented June 28, 2011

+∞

Stefan Loikkanen

Is this being worked on?
This is the only thing that keeps the company i am working for from using it at the moment.
We need it to get "unique" headers from news articles.
We could make our own frontend that does this, but we rather have all search, sort and folding in the same software.
I can understand that this can be a problematic thing in a cluster when all results are not known.

How about this for a solution:
"Field Collapsing" the results in the nodes using Lucene functionality, to reduce the amount of data to be transported.
Then on the node that received the request from the client you do you own "Field Collapsing" when combining the results.

Hope it helps.

Olivier Favre
ofavre commented July 04, 2011

Lucene 3.3 has improved its grouping (more abstract and multiple response per groups, mainly).
A few commits ago, ES has switched to Lucene 3.3 for upcoming version 0.17.
This is good news!

Any idea how long this might take to implement? / Any update status of what still needs to be solved?
Thanks

Shay Banon
Owner
kimchy commented July 04, 2011

Heya, an update on this: I plan to try and tackle this in the next version, see how it goes. The new lucene version does come with grouping support (though, its not going to be tremendously fast, and require more memory). The change requires some internal changes in elasticsearch to represent the fact that grouping is being performed, how to represent it, and get it hooked into the internal single shard search, and distributed search.

Andreas Schmid

+1

richardsyeo

+1. Our use case is...property search results which might contain properties for a new Development (large piece of land being built on by a Developer) which might have properties (Plots) of more than one Style. Properties with same Style might have a different price because they might have slightly bigger garden, etc. We would want to offer the user the ability to collapse results on Development and Style. So if a Development had 100 properties containing 5 styles each style with 20 properties we would expect to see 5 items in the results which we would render in the results differently to indicated number of properties and price range.

vincenttheeten
Andy Nahapetian
nahap commented July 25, 2011

+1

Linus Oleander

+1

Medcl

+1

Jörg Prante

+1

@Shay do you have any updates on this?

I noticed https://issues.apache.org/jira/browse/SOLR-2066

electic

+1 de-duping would be nice.

Giorgio Salluzzo

Hi there, any update on this topic? Thanks in advance.

scriby

+1

Bryan C Green

+1
Seems like a great feature. Glad to see that there is some level of support from Lucene as well.

Nicolas Ippolito

+1

Sébastien Charrier

Hi ! Any active work on / informations about that ticket ?

It's the only missing feature for a full ES use as requester for us.
It would be really, really usefull :)

Tristan Rivoallan

+1 !

Martijn van Groningen
Owner

People that might be interested in using grouping with elastic search can checkout the following link:
https://github.com/martijnvg/elasticsearch-with-local-grouping

The readme describes how grouping can be used.

Jörg Prante

Thank you Martijn. This is a nice effort. Sadly, the fork does not support sharding because it is a port of Lucene grouping contrib. I'm interested in grouping over more than one shards.

Martijn van Groningen
Owner

Hi jprante, the Lucene grouping contrib it self doesn't support distributed grouping. However the the grouping contrib has methods that help a Lucene developer to implement distributed grouping like for example merge search response from different shards. This is also what Solr uses in its distributed grouping implementation. The code in the fork needs some rewriting in order to support distributed grouping.

Alex Brasetvik

Shay posted an update regarding implementing this here: http://elasticsearch-users.115913.n3.nabble.com/0-19-0-Released-tp3792971p3796850.html

The major changes for the next few weeks on 0.20 that I was planning to try and tackle (hopefully successfully :) ) are:

  • Better shard allocation, initially trying to even out shard allocation also based on which index they belong to, to get even distribution also within an index across a cluster.
  • Refactor the field data support, allowing for different pluggable implementations, which can allow for ones that are more optimized for memory usage for example. It will tie in with the mapping allowing to decide which one to use on which field, though the aim is to have sensible auto detected defaults. - Refactor the search execution code, to allow for more interesting search executions, like one that does grouping. Once its done, try and see if we can tackle grouping.
brian

+1 coding one of our search products on es recently, it will index 0.2b docs. and one of the requirements really need this func.

Wijnand Modderman-Lenstra

+1

Markus Schirp
mbj commented April 26, 2012

@guanyum to do facet search on arbitrary key value properties :D ?

Chris Blackwell

+1

tugaanaa

+1 it would be super useful to have this feature for distributed search.

Brian

+1

Jagdeep

+1

mhcdev
mhcdev commented June 15, 2012

+1

Deleted user
ghost commented June 26, 2012

The content you are editing has changed. Reload the page and try again.

+1

Sending Request…

Attach images by dragging & dropping or selecting them. Octocat-spinner-32 Uploading your images… Unfortunately, we don't support that file type. Try again with a PNG, GIF, or JPG. Yowza, that's a big file. Try again with an image file smaller than 10MB. This browser doesn't support image attachments. We recommend updating to the latest Internet Explorer, Google Chrome, or Firefox. Something went really wrong, and we can't process that image. Try again.

David Schovanec
schovi commented June 27, 2012

+1

Meher
meher commented June 28, 2012

+1

Victor Kmita
vkmita commented July 11, 2012

+1

Jérémie BORDIER
ahfeel commented July 23, 2012

+1

Luis Nell

+1

Michael Mahemoff

+1

Roman S. Borschel

+1

Mark Ashcroft

+1

Quin Hoxie

+1

Deleted user

The content you are editing has changed. Reload the page and try again.

-1 Grouping should not happen in core. I belongs in query result pipeline; decoupled from IR fundamentals. A word to the wise, Solr's habit of adopting every bell and whistle anyone wants does not make it more palatable to Enterprise shops; it makes it less. Strategic competitiveness is derived from custom work, not leveraging the same model everyone else is. That said, the general utility of the features are sound. However, even plugin interfaces do not define "loose coupling"; a paradigm I seek in all design work.

Sending Request…

Attach images by dragging & dropping or selecting them. Octocat-spinner-32 Uploading your images… Unfortunately, we don't support that file type. Try again with a PNG, GIF, or JPG. Yowza, that's a big file. Try again with an image file smaller than 10MB. This browser doesn't support image attachments. We recommend updating to the latest Internet Explorer, Google Chrome, or Firefox. Something went really wrong, and we can't process that image. Try again.

CptnKirk

+1

Noam Y. Tenne

+1

Thomas Drevon

+1

The startup company I work (https://github.com/bengler) for really needs this feature. Do you have a collection plate or somesuch where one can put money in order to fast-track something?

Jaroslav Kalistsuk

+1

Kaspars Sprogis

+1

brian

@mbj thanks for your comment, i will have a try.

Markus Schirp
mbj commented October 27, 2012

@guanyum My comment was helpful? How?

Patryk Wasik

+1

hlinski

+1

nelalx

+1

Aidan

+1

Erling Wegger Linde

+1

mahdeto

+1

Magnus Haug

+1

Inal Djafar

+1

Bart Gajderowicz

+1

Steeve Morin

+1

Buck Golemon

+1

msathis

+1

khsibr

+1

Paul Conroy

+1

Otu Ekanem

+1 ;)

hawky-4s-

+1

Woody Peterson

+1

deepeye

+1

Maggie Nelson

+1

Mikalai Zubok

+1

k.bigwheel

+1

Nicolas Schwartz

+1 please !

Nicolas Colomer

+1 !

Meidan

+1

Ivan Brusic

Can we please stop with the +1s? It should be apparent that after three years, the ElasticSearch team does not choose feature requests based on GitHub +1s.

If you want updates, click the the "Watch thread" button below.

Son

True but brutal.

Having to write hundreds of lines of code to mimic field-collapsing functionality is not so hard but not quite fulfilling.

Ivan Brusic

Just wanted to clarify that my comment was not directed at the ElasticSearch team but at the perceived workflow of GitHub. Some projects might choose which issues to work based on +1s, but ElasticSearch is not one of them. No harm, no foul. +1 comments are simply noise at this point. Comments can be productive. Instead of a +1, a sample use case can be described. Out of the 150+ comments, there are a handful of good suggestions. That said, an update would be nice!

Sorry for increasing the noise. :)

tintin04

Until ES team noticed and integrated it, is there anyway to do this in ES 0.90 ? Is parent-child solution good enough ?

Anyway, field-collapsing is one of cool and handy feature of search engine, +1 for it

Edward Smit

Don't hold your breath waiting on Field Collapsing. It won't be part of the 0.90 final. The ES team has to do a substantial refactoring before they will be able to implement this feature in a satisfying way. Probably the best course of action is to implement your own, client-side, or investigate if you can accomplish the same goals using a Parent-Child design.
Above conclusion is my own, based on the responses of the Dev Team during the latest ElasticSearch User Group NL Meetup where the whole Dev Team was present.

Branden Visser

+1

Branden Visser mrvisser referenced this issue in oaeproject/Hilary May 09, 2013
Closed

(Facets) Facet searches on resource type #489

Rashid Khan rashidkpc referenced this issue in elasticsearch/kibana May 14, 2013
Closed

Creating own query #80

Arnok13
Arnok13 commented May 24, 2013

Any news on a milestone for this feature ?

Marc Melvin
lusid commented May 29, 2013

In my opinion, this is the only thing Elastic Search is missing.

phoenixbai

+1!

loachli

+1

Stein Kåre Skytteren

+1

Alexander

+1

Greg Smith

+1

Alex McFadyen

It won't be part of the 0.90 final.

0.9 came and went. Do we have any idea where on the road map this might be now? Seems to have a lot of support / interest.

shadow000fire

I've been hearing about a new Aggregates framework. Will that cover this functionality?

Matt Weber

@shadow000fire no, aggregations are similar to facets.

shadow000fire
Bob Tiernay

@shadow000fire Just curious about this feature. Do you have a link to information on the aggregates framework? I'm wondering if it might be able to solve my issue decribed in #3456. Thanks

Ivan Brusic

The aggregate framework is described here: #3300

Praveen

+1

Adit Saxena

+1

Hello ES Community,
I'm also figuring if there is a raw equivalence of grouping or if exists for now a pattern to resolve this situation.

My problem:

  • I have a tons of documents to search
  • each article has many (1 to 10) variants which I'd like to present the best version match
  • we can forget about the other docs versions with lower score
  • (we list 20 results by page)

How to accomplish this? Here's some thoughts:
a) get 200 results per time and filter out which I don't need
b) use two filters
1. some facet query (see below)
2. query something like
SELECT [elasticsearch query] WHERE [...] AND version_ids IN ('x', 'y', 'z')

It seems Clinton Gormley-2 on a post* on nabble.com also tried to explain a workaround, but I really did not understand how it works, can somebody give me a help?

Thanks, regards, Adit

*reference: http://elasticsearch-users.115913.n3.nabble.com/Getting-Distinct-Values-td3830953.html

Son

I think what Clinton Gormley-2 explained probably only about step 1 (facet query, be it terms/stats...) in your option b). You still need to do step 2 with the latest ES if I am not wrong.

Options b) makes more sense than option a) btw. At least can make use of some indexing facilities via face queries.

Adit Saxena

Hi! Sorry for my late reply.. I'm trying my best to study every possible alternative (aka RTFM) before asking what's already answered!

I'm still figuring how facets & terms/stats can resolve "step 1", here's my attempts:

@shyos on my question comments "Term facet does this very well"

I think I can manage Step 2, would you or the community suggest how to rewrite the last query on my pastebin (the facet / term / stats query)?

Thank you for your help :)

PS: the answer/direction could also be some pseudo-code I can run on my client-side (I use ruby but anything would be good)

Alexis Okuwa

@kimchy after 3 years 181 comments this is the 3rd oldest open issue on github for elasticsearch. I am not sure that this is going to get supported or not but it looks like there is a huge support within the community. I am sure most of the people in here can tell you that you have one o f the greatest search index/database out there features like this just help solidify that.

Adit Saxena

any ideas on how to get around this problem?

@phungleson you did suggest "Having to write hundreds of lines of code to mimic field-collapsing functionality is not so hard but not quite fulfilling."

Even it's not fulfilling I'm assigned to get this working. Could you suggest me any direction on where to start or some basic ideas/principals to follow accomplish pagination with grouping?

Ivan Brusic
Son

@saxxi the simple idea is the same with one posted here, we need to do 2 requests.
First request to do a faceting to get some grouped category_ids.
Second request get full docs information based on category_ids.

Sorting of categories do in the first request. Pagination of category_ids do manually in code after first and before second. Secondary sorting of docs can do in second request or manually.

One annoying issue we have is that we write a lot. By the time we do the second request, there might be some new docs and the first faceted result already out-dated.

@brusic Not sure if the issue of distributed environment can be solved if we route based on category_id?

Paul Masurel

What about implementing grouping/collapsing as a plugin?

With 328608f I feel like there is not much obstacle to writing a search plugin, as there been any effort in this direction?

Ivan Brusic

Creating a plugin is not the hard part, it is creating an efficient and correct implementation in a sharded environment. I just glanced at the field collapsing feature on Solr and I from what I read, it does not work correctly with shards unless all the documents that are grouped belong to the same shard.

With custom routing, it would be possible to do in elasticsearch, but that would only apply to specific use cases. Elasticsearch already has issues with not having correct counts with facets. I am eagerly awaiting for the new aggregation framework before re-investigating. I doubt there is anything in the aggregation framework itself, but perhaps a refactoring to the underlying classes will help other features.

Paul Masurel

Only ngroups (returning the number of groups) does not work correctly if documents belonging to a group are not in the same shard. Grouping on the other hands works perfectly fine in a sharded environment.

Adit Saxena

Hi @brusic & @phungleson, thanks for your inputs. I've tried hard to follow your directions and I've understood all but the faceted query part (sorry!):

I've only managed to find the results with these facets:

eg. results = {
  hits: [
    { id: "the_game", _score: 3, author_id: 'john'},
    { id: "the_play", _score: 2, author_id: 'john'},
    { id: "the_good", _score: 1, author_id: 'mark'}
    ...
  ],
  facets: {
     author: {
         "john" : 30, // total docs found, this would be better: "john": ["the_game", "the_play", ...], "mark": ["the_good", ...]
         "mark" : 10
     }
  }
}

Nevertheless, here's what I've accomplished.


Assumptions.

1) I'm looking for relevant content
2) I've assumed that first 300 docs are relevant, so I consider restricting my research to this selection, regardless many or some of these are from the same few authors.
3) for my needs I didn't "really" needed full pagination, it was enough a "show more" button updated through ajax.

Here's my actual ruby pseudo-code: https://gist.github.com/saxxi/6495116

I still need to test this in production, but for now it looks promising. Thanks to all!

Son

@saxxi better to elaborate your question in group chat or stack over flow rather in Github issues, particularly this issue, I guess.

Alexis Okuwa

@brusic I was thinking the best way to run this in a distrubuted cluster maybe is to do the grouping at the merge sort. Assuming the values are sorted one the collapse feleds it would be much easier to remove dups then and not before a sort or once they have merged onto a single machine.

shadow000fire

@wojons If you're talking about doing this as a plugin, I've done a few different ways. Note that they're all workaround a to a native implementation and may or may not perform very well depending on your data.

1- Do the query and sort by the collapse field. Iterate through the hits and remove anything after the first N hits per "group". Then re-order by whatever field you want. The final sort will not be accurate accross the global result set because the shards will have sorted by your collapse field and returned those top G hits. You may have to may multiple queries to get all the groups, which can either be done with scroll or from/size.

2- Similar to number #1 but sort results by score and iterate through the hits to create the groups yourself. This works ok if you don't get too many hits per group more than you want.

(Note that the paging required by both of these can be improved hu re-doing the query with an additional filter after you've identified one or more new groups.

Stevie Graham

hate to be that guy, but +1

Adit Saxena

@phungleson - I've updated my stackoverflow answer and gist. I'm thinking on joining soon the IRC community as well, I hope to see you there too.

Paul Masurel

@wojons Collapsing is implemented that way in several enterprise search engine. One of the main problem is that no matter how many documents will be returned by the shards, it might not be sufficient to fill your page of hit after postprocessing. When collapsing for diversity (like a search engine like google does) it is not such a big problem to collapse the first result and then fallback to uncollapsed search. If your use case is for instance to group result per category in a e-commerce search engine, this may not be an option for you.

Paul Masurel

If some of you are interested in the way it is done in Solr, I described it in a blog post : http://fulmicoton.com/posts/grouping-in-solr/

Mihai Oprea

+1 :)

Oliver B. Fischer

+1 This just what I need +1000

Yılmaz

+1

Ivan Brusic

The issue of field collapsing was address slightly in this blog post: http://www.elasticsearch.com/blog/from-amsterdam-with-love-elasticsearchs-second-company-all-hands/

"We again fleshed out what is needed in order to properly support field collapsing in a distributed environment execution, as well as the ability to get inner hits (for nested / parent child cases). We have a good idea on the type of refactoring we need in our search execution infrastructure, and hope to tackle it post 1.0."

The elasticsearch team is working on it and the timetable is somewhere post 1.0. You can now stop with the +1s. :)

Michael Scharf (Github)

+1
to make "somewhere post 1.0" not too long after 1.0 ;-)

Marius Pop

+1 :)

vyasarajgk

+1:)

Yonatan Most

+1

devour25

I've been reading http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/search-aggregations.html,
it says
"Bucketing
A family of aggregations that build buckets, where each bucket is associated with a key and a document criteria. When the aggregations is executed, the buckets criterias are evaluated on every document in the context and when matches, the document is considered to "fall in" the relevant bucket. By the end of the aggreagation process, we’ll end up with a list of buckets - each one with a set of documents that "belong" to it."

for each document returned, it would have a score, is it possible to select only top 5 results from each bucket and all together order by scores of these documents?
(Real case scenario is a search engine only wants to select 5 highest score documents that belongs to each owner, but all the selected documents need to be put together and determine which document displays first)

thanks

Daniel Rech
dmr commented January 15, 2014

+1

Simon Willnauer
Owner

+1

Ivan Brusic

Wait, did Simon just +1 this issue? :)

Paul Masurel

@s1monw Could you communicate on whether there is an ongoing project at elasticsearch on that? I was just thinking about resuming a grouping plugin project next weekend. I'd better drop it if the functionality will be shipped in next release.

Simon Willnauer
Owner

@poulejapon obviously this feature is of great demand so I am pretty sure that this is high prio as it always was. I can't make any promises when this will be implemented but I can promise it's not shipping in the next release and very unlikely in 1.1. This feature to be done right needs a reasonable refactoring on the search execution layer that is why we didn't crank it out already. The demand is I think obvious and there is no need for further +1 on it unless you really need to express yourself as I did since I think it's important. Stay tuned there is hope! :)

Sascha Sander

+1

Kumen
Kumen commented March 04, 2014

+1

Adrian Philipp
adri commented March 10, 2014

+1

Tyler Kellogg

+1

Daniil Yaroslavtsev

+1

David Navarro

+1

Bjørn Bråthen

+1

Piotrek Majewski

+1

Bruno Miranda
brupm commented April 01, 2014

:+1:

Firfi
Firfi commented April 03, 2014

+1

imarsman

This would be incredibly useful for the application I am writing for my company. I am, however, amazed at how capable Elasticsearch is already that I feel it would be rude not to say thank-you before adding my YES to this request for this feature to be added.

petard

+1

Greg Solovyev

+1 this is a tie breaker for us right now when evaluating ES vs Solr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.