Hi Ishan, I definitely should write a test. It's supposed to be a drop-in replacement for the existing Join query. I wasn't sure if I should hijack SOLR-7090, or maybe LUCENE-3759, or just open a new JIRA. Please advise!
Or I'm happy to continue discussing high level on this thread. Best, Scott On Wed, Sep 30, 2015 at 4:28 PM, Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > 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 <dragonsi...@gmail.com> 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? >> > >
