Hi Scott, I've replied to your comment on SOLR-7090. I just had a look at the your fulljoin implementation, but I wasn't sure if I follow this properly. Maybe a unit test would help? Also, do you plan to open a JIRA (or, maybe, use SOLR-7090 JIRA itself, so as to keep all related efforts together in one issue) to discuss your full join approach? Regards, Ishan
On Thu, Oct 1, 2015 at 1:19 AM, Scott Blum <[email protected]> wrote: > So I went down the route of creating a new QParser named "fulljoin", and I > have it essentially working. > > https://github.com/fullstorydev/lucene-solr/commits/scottb/fulljoin > > Basically, I copied JoinQParserPlugin, ripped out the local index "from" > processing, and replaced it with a SolrCloud facet query. IE, you facet > over the 'from' field and turn the facet result into the set of terms you > care about. > > The part I need some help on is that I'm fairly sure the caching > (equality) is wrong. If the collection gets updated in such a way that the > results of the facet query would change, I don't think I'm properly > invalidating the cache / failing an equality check. > > I assume this is what JoinQuery.fromCoreOpenTime does, handle equality > correctly so that if the underlying core is updated, the cache will get > invalidated? I need to do something similar such that if the results of > the facet query would return a different term list, I can change the > equality computation. Any advice? >
