Re: Cross-node joins

[Scott Blum <dr...@gmail.com>]

Updated SOLR-7090 with a not fully-working patch.

On Wed, Sep 30, 2015 at 5:45 PM, Scott Blum <dr...@gmail.com> 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 <
> ichattopadhyaya@gmail.com> 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 <dr...@gmail.com> 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 <
>>> ichattopadhyaya@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 <dr...@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?
>>>>>
>>>>
>>>>
>>>
>>
>