Alright, I'll put something on SOLR-7090 in a bit. Meanwhile, I'm trying to get a basic test running, and running into a stupid problem... I am trying to write a cloud and non-cloud code path for the facet query. What I want to do is create a solrj HttpSolrClient either way, but I can't figure out how to create one to do a local query on a known core. So I'm doing some convoluted stuff where I use a LocalSolrQueryRequest and SolrQueryResponse, and it seems pretty wonky.
Any tips? On Wed, Sep 30, 2015 at 4:36 PM, Ishan Chattopadhyaya < [email protected]> wrote: > 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? >>>> >>> >>> >> >
