Solr Block Join Query matching Parent documents that have multiple children

[Jamie Johnson <je...@gmail.com>]

I have the following documents indexed
<response>
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">1</int>
</lst>
<result name="response" numFound="6" start="0">
<doc>
<str name="type_s">physicalcharacteristics</str>
<str name="test_haircolor_txt">Black</str>
<str name="test_eyecolor_txt">Green</str>
</doc>
<doc>
<str name="type_s">physicalcharacteristics</str>
<str name="test_haircolor_txt">Red</str>
<str name="test_eyecolor_txt">Brown</str>
</doc>
<doc>
<str name="type_s">person</str>
<str name="key">1</str>
</doc>
<doc>
<str name="type_s">physicalcharacteristics</str>
<str name="test_eyecolor_txt">Pink</str>
<str name="test_haircolor_txt">Purple</str>
</doc>
<doc>
<str name="type_s">physicalcharacteristics</str>
<str name="test_haircolor_txt">Brown</str>
<str name="test_eyecolor_txt">Blue</str>
</doc>
<doc>
<str name="type_s">person</str>
<str name="key">2</str>
</doc>
</result>
</response>

I am able to get back all people that have child documents with brown hair
and blue eyes OR pink eyes and purple hair, but is there a way to get back
parent documents that have children that are both?

If we have another level within physicalcharacteristics is specifying the
parent type sufficient for the parser to traverse back to the root document
(i.e. person in this case)?

Lastly if the type physicalcharacteristics can appear at multiple levels is
the best way of specifying the type to include the path so that we can
target different levels?  So for instance type_s would be
person/physicalcharacteristic or person/foo/physicalcharacteristic so I
could target the correct level I suppose?

Re: Solr Block Join Query matching Parent documents that have multiple children

[Mikhail Khludnev <mk...@griddynamics.com>]

On Sat, Dec 20, 2014 at 1:32 AM, Jamie Johnson <je...@gmail.com> wrote:
>
> I have the following documents indexed
> <response>
> <lst name="responseHeader">
> <int name="status">0</int>
> <int name="QTime">1</int>
> </lst>
> <result name="response" numFound="6" start="0">
> <doc>
> <str name="type_s">physicalcharacteristics</str>
> <str name="test_haircolor_txt">Black</str>
> <str name="test_eyecolor_txt">Green</str>
> </doc>
> <doc>
> <str name="type_s">physicalcharacteristics</str>
> <str name="test_haircolor_txt">Red</str>
> <str name="test_eyecolor_txt">Brown</str>
> </doc>
> <doc>
> <str name="type_s">person</str>
> <str name="key">1</str>
> </doc>
> <doc>
> <str name="type_s">physicalcharacteristics</str>
> <str name="test_eyecolor_txt">Pink</str>
> <str name="test_haircolor_txt">Purple</str>
> </doc>
> <doc>
> <str name="type_s">physicalcharacteristics</str>
> <str name="test_haircolor_txt">Brown</str>
> <str name="test_eyecolor_txt">Blue</str>
> </doc>
> <doc>
> <str name="type_s">person</str>
> <str name="key">2</str>
> </doc>
> </result>
> </response>
>
> I am able to get back all people that have child documents with brown hair
> and blue eyes OR pink eyes and purple hair, but is there a way to get back
> parent documents that have children that are both?
>
Did you try nest just boolean query?
q={!parent which=type_s:person}+test_haircolor_txt:Purple
+test_eyecolor_txt:Pink


> If we have another level within physicalcharacteristics is specifying the
> parent type sufficient for the parser to traverse back to the root document
> (i.e. person in this case)?
>

usually, there is no problem
http://blog.griddynamics.com/2013/12/grandchildren-and-siblings-with-block.html


>
> Lastly if the type physicalcharacteristics can appear at multiple levels is
> the best way of specifying the type to include the path so that we can
> target different levels?  So for instance type_s would be
> person/physicalcharacteristic or person/foo/physicalcharacteristic so I
> could target the correct level I suppose?
>
this is more problematic. possible workaround is to OR two alternative
nested queries.

-- 
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics

<http://www.griddynamics.com>
<mk...@griddynamics.com>