lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Bernstein (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-8409) Complex q param in Streaming Expression results in a bad query
Date Thu, 04 Feb 2016 03:34:39 GMT

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

Joel Bernstein commented on SOLR-8409:
--------------------------------------

Ok this interesting. What's below is before this patch:

I ran this test, which I expected to break because the parser would have trouble with quotes
inside the quotes. I was surprised to find that it worked perfectly.
{code}
 expression = StreamExpressionParser.parse("parallel(collection1,"
                                              + "rollup("
                                                + "search(collection1, q=\"a_s:(\"hello0\"
OR \"hello3\" OR \"hello4\")\", fl=\"a_s,a_i,a_f\", sort=\"a_s asc\", partitionKeys=\"a_s\"),"
                                                + "over=\"a_s\","
                                                + "sum(a_i),"
                                                + "sum(a_f),"
                                                + "min(a_i),"
                                                + "min(a_f),"
                                                + "max(a_i),"
                                                + "max(a_f),"
                                                + "avg(a_i),"
                                                + "avg(a_f),"
                                                + "count(*)"
                                              + "),"
                                              + "workers=\"2\", zkHost=\""+zkServer.getZkAddress()+"\",
sort=\"a_s asc\")"
                                              );
{code}

Below is the what was sent to the workers. Notice the quotes are not escaped at all:

{code}
rollup(search(collection1,q="a_s:("hello0" OR "hello3" OR "hello4")",fl="a_s,a_i,a_f",sort="a_s
asc",partitionKeys=a_s,zkHost="127.0.0.1:52813/solr"),over=a_s,sum(a_i),sum(a_f),min(a_i),min(a_f),max(a_i),max(a_f),avg(a_i),avg(a_f),count(*))

rollup(search(collection1,q="a_s:("hello0" OR "hello3" OR "hello4")",fl="a_s,a_i,a_f",sort="a_s
asc",partitionKeys=a_s,zkHost="127.0.0.1:52813/solr"),over=a_s,sum(a_i),sum(a_f),min(a_i),min(a_f),max(a_i),max(a_f),avg(a_i),avg(a_f),count(*))
 {code}

Below is what was sent from the workers to the shards. Notice that the query is correct. 

{code}
   [junit4]   2> 36804 INFO  (qtp1665513927-67) [n:127.0.0.1:52821_ c:collection1 s:shard2
r:core_node1 x:collection1] o.a.s.c.S.Request [collection1]  webapp= path=/select params={q=a_s:("hello0"+OR+"hello3"+OR+"hello4")&distrib=false&fl=a_s,a_i,a_f&fq={!hash+workers%3D2+worker%3D0}&sort=a_s+asc&partitionKeys=a_s&wt=json&version=2.2}
hits=3 status=0 QTime=1
   [junit4]   2> 36804 INFO  (qtp637545437-123) [n:127.0.0.1:52829_ c:collection1 s:shard2
r:core_node3 x:collection1] o.a.s.c.S.Request [collection1]  webapp= path=/select params={q=a_s:("hello0"+OR+"hello3"+OR+"hello4")&distrib=false&fl=a_s,a_i,a_f&fq={!hash+workers%3D2+worker%3D1}&sort=a_s+asc&partitionKeys=a_s&wt=json&version=2.2}
hits=3 status=0 QTime=1
   [junit4]   2> 36804 INFO  (qtp682745908-97) [n:127.0.0.1:52825_ c:collection1 s:shard1
r:core_node2 x:collection1] o.a.s.c.S.Request [collection1]  webapp= path=/select params={q=a_s:("hello0"+OR+"hello3"+OR+"hello4")&distrib=false&fl=a_s,a_i,a_f&fq={!hash+workers%3D2+worker%3D1}&sort=a_s+asc&partitionKeys=a_s&wt=json&version=2.2}
hits=1 status=0 QTime=0
   [junit4]   2> 36804 INFO  (qtp682745908-471) [n:127.0.0.1:52825_ c:collection1 s:shard1
r:core_node2 x:collection1] o.a.s.c.S.Request [collection1]  webapp= path=/select params={q=a_s:("hello0"+OR+"hello3"+OR+"hello4")&distrib=false&fl=a_s,a_i,a_f&fq={!hash+workers%3D2+worker%3D0}&sort=a_s+asc&partitionKeys=a_s&wt=json&version=2.2}
hits=3 status=0 QTime=0
{code}

So it appears that the parser doesn't even need the quotes nested within quotes to be escaped.
I'm assuming that's because it's splitting on the comma and the equals sign and then removing
the outer quotes.



> Complex q param in Streaming Expression results in a bad query
> --------------------------------------------------------------
>
>                 Key: SOLR-8409
>                 URL: https://issues.apache.org/jira/browse/SOLR-8409
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrJ
>    Affects Versions: Trunk
>            Reporter: Dennis Gove
>            Priority: Minor
>              Labels: streaming, streaming_api
>         Attachments: SOLR-8409.patch, SOLR-8409.patch
>
>
> When providing an expression like 
> {code}
> stream=search(people, fl="id,first", sort="first asc", q="presentTitles:\"chief executive
officer\" AND age:[36 TO *]")
> {code}
> the following error is seen.
> {code}
> no field name specified in query and no default specified via 'df' param
> {code}
> I believe the issue is related to the \" (escaped quotes) and the spaces in the q field.
If I remove the spaces then the query returns results as expected (though I've yet to validate
if those results are accurate).
> This requires some investigation to get down to the root cause. I would like to fix it
before Solr 6 is cut.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message