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 elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/91919a48-0892-4878-890b-e14c67fd40b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.