You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Neil Ireson <n....@sheffield.ac.uk> on 2013/11/22 13:28:53 UTC

Possible parent/child query bug

Note sure if this is a bug but, for me, it was unexpected behaviour.

http://localhost:8090/solr/select?q={!child+of=doc_type:parent}*:* 

returns all the child docs, as expected, however

http://localhost:8090/solr/select?q={!child+of=doc_type:parent}

returns all the parent docs. 

This seems wrong to me, especially as the following query also returns all the parent docs, which would make the two query equivalent:

http://localhost:8090/solr/select?q={!parent+which=doc_type:parent}




Re: Possible parent/child query bug

Posted by Mikhail Khludnev <mk...@griddynamics.com>.
On Fri, Nov 22, 2013 at 6:18 PM, Neil Ireson <n....@sheffield.ac.uk>wrote:

>
> If the "child of” query matches both parent and child docs it returns the
> child documents but a spurious numFound.


follow up https://issues.apache.org/jira/browse/SOLR-5553


-- 
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics

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

Re: Possible parent/child query bug

Posted by Neil Ireson <n....@sheffield.ac.uk>.
Hi Mikhail,

You are right. 

If the "child of” query matches both parent and child docs it returns the child documents but a spurious numFound.

For the  “parent which” query if it matches both parent and child docs it returns a handy error message “child query must only match non-parent docs..."




On 22 Nov 2013, at 14:03, Mikhail Khludnev <mk...@griddynamics.com> wrote:

> Neil,
> quick hint. Can't you run Solr (jetty) with -ea ? my feeling is that nested
> query (which you put
> *:*<http://localhost:8090/solr/select?q=%7B%21child+of=doc_type:parent%7D*:*>)
> should be orthogonal to children, that's confirmed by assert. That's true
> for {!parent} at least.
> 
> 
> On Fri, Nov 22, 2013 at 5:40 PM, Neil Ireson <n....@sheffield.ac.uk>wrote:
> 
>> Some further odd behaviour. For my index
>> 
>> http://localhost:8090/solr/select?q={!child+of=doc_type:parent}*:*
>> 
>> Returns a numFound=“22984”, when there are only 2910 documents in the
>> index (748 parents, 2162 children).
>> 
>> 
>> 
>> 
>> On 22 Nov 2013, at 12:28, Neil Ireson <n....@sheffield.ac.uk> wrote:
>> 
>>> 
>>> Note sure if this is a bug but, for me, it was unexpected behaviour.
>>> 
>>> http://localhost:8090/solr/select?q={!child+of=doc_type:parent}*:*
>>> 
>>> returns all the child docs, as expected, however
>>> 
>>> http://localhost:8090/solr/select?q={!child+of=doc_type:parent}
>>> 
>>> returns all the parent docs.
>>> 
>>> This seems wrong to me, especially as the following query also returns
>> all the parent docs, which would make the two query equivalent:
>>> 
>>> http://localhost:8090/solr/select?q={!parent+which=doc_type:parent}
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
> 
> <http://www.griddynamics.com>
> <mk...@griddynamics.com>


Re: Possible parent/child query bug

Posted by Mikhail Khludnev <mk...@griddynamics.com>.
Neil,
quick hint. Can't you run Solr (jetty) with -ea ? my feeling is that nested
query (which you put
*:*<http://localhost:8090/solr/select?q=%7B%21child+of=doc_type:parent%7D*:*>)
should be orthogonal to children, that's confirmed by assert. That's true
for {!parent} at least.


On Fri, Nov 22, 2013 at 5:40 PM, Neil Ireson <n....@sheffield.ac.uk>wrote:

> Some further odd behaviour. For my index
>
> http://localhost:8090/solr/select?q={!child+of=doc_type:parent}*:*
>
> Returns a numFound=“22984”, when there are only 2910 documents in the
> index (748 parents, 2162 children).
>
>
>
>
> On 22 Nov 2013, at 12:28, Neil Ireson <n....@sheffield.ac.uk> wrote:
>
> >
> > Note sure if this is a bug but, for me, it was unexpected behaviour.
> >
> > http://localhost:8090/solr/select?q={!child+of=doc_type:parent}*:*
> >
> > returns all the child docs, as expected, however
> >
> > http://localhost:8090/solr/select?q={!child+of=doc_type:parent}
> >
> > returns all the parent docs.
> >
> > This seems wrong to me, especially as the following query also returns
> all the parent docs, which would make the two query equivalent:
> >
> > http://localhost:8090/solr/select?q={!parent+which=doc_type:parent}
> >
> >
> >
>
>


-- 
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics

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

Re: Possible parent/child query bug

Posted by Neil Ireson <n....@sheffield.ac.uk>.
Some further odd behaviour. For my index

http://localhost:8090/solr/select?q={!child+of=doc_type:parent}*:* 

Returns a numFound=“22984”, when there are only 2910 documents in the index (748 parents, 2162 children).




On 22 Nov 2013, at 12:28, Neil Ireson <n....@sheffield.ac.uk> wrote:

> 
> Note sure if this is a bug but, for me, it was unexpected behaviour.
> 
> http://localhost:8090/solr/select?q={!child+of=doc_type:parent}*:* 
> 
> returns all the child docs, as expected, however
> 
> http://localhost:8090/solr/select?q={!child+of=doc_type:parent}
> 
> returns all the parent docs. 
> 
> This seems wrong to me, especially as the following query also returns all the parent docs, which would make the two query equivalent:
> 
> http://localhost:8090/solr/select?q={!parent+which=doc_type:parent}
> 
> 
> 


Re: Possible parent/child query bug

Posted by Mikhail Khludnev <mk...@griddynamics.com>.
On Fri, Nov 22, 2013 at 4:28 PM, Neil Ireson <n....@sheffield.ac.uk>wrote:

> returns all the child docs, as expected, however
>
> http://localhost:8090/solr/select?q={!child+of=doc_type:parent}
>
> returns all the parent docs.
>

aha. I remember it. I implemented this special case for reusing segmented
parent filter in Solr's q/fq
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/search/join/BlockJoinParentQParser.java?source=cc#L55
It's lack of documentation.


-- 
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics

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