I think LUCENE-3759 is not a good place, since this is a Solr specific implementation. Please feel free to use SOLR-7090. Based on my idea of your implementation, it wasn't clear to me whether or not the intention of the patch is the same as what SOLR-7090 (at a high level), as per the description there, is trying to solve. But if ever we feel the need, we can always split the issue/impl later; or even resolve-as-duplicate two different JIRA issues later. So, please feel free to choose as you see things fit.
On Thu, Oct 1, 2015 at 2:02 AM, Scott Blum <[email protected]> wrote: > 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 < > [email protected]> 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 <[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? >>> >> >> >
