[ 
https://issues.apache.org/jira/browse/SOLR-11353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132158#comment-18132158
 ] 

Nick Shanin commented on SOLR-11353:
------------------------------------

>From code reading against apache/main b73f03976fa, without childFilter, 
>[child] returns all block descendants of each root, which is the documented 
>default 
>(solr/solr-ref-guide/modules/query-guide/pages/document-transformers.adoc:146, 
>solr/core/src/java/org/apache/solr/response/transform/ChildDocTransformer.java:224).
> The fq only changes which roots match. Is closure OK, or do the blocks in 
>your index not match this?

🤖 AI-generated 🤖

> Incorrect children returned on facet query
> ------------------------------------------
>
>                 Key: SOLR-11353
>                 URL: https://issues.apache.org/jira/browse/SOLR-11353
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 6.6
>            Reporter: Chris de Kok
>            Priority: Major
>              Labels: parent, parentchild
>
> When I query for child documents like
> &fl=id,priref,[child parentFilter=parent:images]&fq=database:"images"
> Everything works ok the correct children are returned.
> Now if I add a fq parent which filters on children:
> &fq={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
> 41.30859375,-95.2734375]
> Suddenly I see incorrect children being returned.
> {
> "id":"images_397",
> "database":"images",
> "_childDocuments_":[
> {
>     "database":"artists_child"
> }
> This child document belongs to a different parent record.
> If i change it to something like:
> &fq={!parent which="parent:images"}(database:"images_child" AND 
> geo:[38.671875,-101.25 TO 41.30859375,-95.2734375])
> It does seem to work but obviously it shouldn't behave like this.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to