Updated SOLR-7090 with a not fully-working patch. On Wed, Sep 30, 2015 at 5:45 PM, Scott Blum <[email protected]> wrote:
> 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? >>>>> >>>> >>>> >>> >> >
