Yes, I think this is somehow related to Matt's Join Filter https://github.com/elasticsearch/elasticsearch/pull/3278
Jörg On Sat, Jul 19, 2014 at 4:24 AM, Don Clore <[email protected]> wrote: > I am pretty sure this is not supported, but it'd be great to explicit > confirmation/denial. > > So....document types A and B, where there's an N:M relationship between A > and B, and document type B has a list of the document A instances that > relate to it. > > More concretely A == a sports Player data type, and B is a set of new > stories. The Story type has a list of the ids of Players that the story > is about/related to. > > So....I know the terms lookup filter allows one to use a single document > as the source of the terms for the lookup. What we'd like to be able to > do is expose a faceted/aggregations-based UI to the user that allows her to > perform a variety of filtering operations on Players over a fairly > extensive set of criteria, and then have the resulting set of Player > document ids serve as the lookup into the Story stories, i.e., get all the > stories that relate to the Player result set. > > Obviously, we'd ideally like to do this in a single query, or failing > that, have some reasonably efficient way to issue the two query/filters > (passing a large result set of ids over the wire seems like a bad idea; I'm > new to ES, but...this kind of thing was never great with Solr). > > One idea I had (perhaps half-baked) was to create a PlayerResultSet type, > with an id deterministically fashioned from the query/filter predicates > such that the same user filtering action would result in the same > PlayerResultSet id each time; we'd issue a terms lookup filter request > using the PlayerResultSet id, if it fails because the PlayerResultSet > document doesn't exist, then we'd have to issue the filter for the Players, > construct a PlayerResultSet doc and index it, and query for the Stories > that have those Player Ids; not sure if it would be worse to issue all the > ids in a query, or index the PlayerResultSet doc with Refresh==true (or > issue the query and queue up the PlayerResultSet doc for later indexing, or > whatever). > > The Player data should be fairly static; we could delete the documents and > recreate them each time we refresh Player data. > > Ok, that sounds pretty awful, I'm hoping someone has a less Rube-Goldberg > approach; obviously, I'm sort of building in my filter query caching > mechanism, hopefully something like this can be more easily achieved with > the built-in filter caching. > > thanks for any insights, > Don > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/91919a48-0892-4878-890b-e14c67fd40b5%40googlegroups.com > <https://groups.google.com/d/msgid/elasticsearch/91919a48-0892-4878-890b-e14c67fd40b5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEMzKNuuBvuTt5XTLN6gMuePrVDP-%3DyjyQ0pWnPJ5NK9w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
