Re: Surround query parser not working?

[William Bell]

Can we get a sample fieldType and field definition?

Thanks.


On Mon, Jul 8, 2013 at 8:40 AM, Jack Krupansky j...@basetechnology.comwrote:

 Yes, you should be able to used nested query parsers to mix the queries.
 Solr 4.1(?) made it easier.

 -- Jack Krupansky

 -Original Message- From: Abeygunawardena, Niran
 Sent: Monday, July 08, 2013 7:00 AM
 To: solr-user@lucene.apache.org
 Subject: Re: Surround query parser not working?


 Hi,

 Thanks. I found out that my issue was the default field (df) was being
 ignored and I had to specify the parameter by adding df=text in the URL.

 Thank you for updating the wiki page on the surround parser:
 http://wiki.apache.org/solr/**SurroundQueryParserhttp://wiki.apache.org/solr/SurroundQueryParser

 Hopefully, ordered proximity searches will be supported in the edismax
 query parser itself as the surround query parser is not as good as the
 edismax parser: 
 https://issues.apache.org/**jira/browse/SOLR-3101https://issues.apache.org/jira/browse/SOLR-3101
 Is there a way to AND the surround parser query with the edismax query so
 the ordered proximity search can be run through the surround query parser
 and the results combined/queried with the edismax query parser for other
 parts of the query? Can nested queries support this?

 Thanks,
 Niran


 Niran -

 Looks like you're being bitten by a known feature* of the surround query
 parser.  It does not analyze the text, as some of the other more commonly
 used query parsers does.  The dismax, edismax, and lucene query parsers
 all leverage field analysis on the query terms or phrases. The surround
 query parser just takes the terms as-is.  It's by design, but not
 necessarily something that can't at least be optionally available.  But as
 it is, you'll need to lowercase, at least.  Be careful with index-time
 stemming, as you'd have to account for that in the surround query parser
 syntax by wildcarding things a bit.  Instead of searching for finding,
 one would use find* (and index without stemming) in the query to match
 finds, finding.  It was by design to not analyze in the surround query
 parser because it can be handy to use less analysis tricks at index time,
 and let the query itself be more sophisticated to allow more flexible and
 indeed more complex query-time constructs.

Erik

 * 
 http://wiki.apache.org/solr/**SurroundQueryParser#**Limitationshttp://wiki.apache.org/solr/SurroundQueryParser#Limitations-
  though it'd be useful to have analysis at least optionally available.




-- 
Bill Bell
billnb...@gmail.com
cell 720-256-8076

Re: Surround query parser not working?

[Abeygunawardena, Niran]

Hi,

Thanks. I found out that my issue was the default field (df) was being ignored 
and I had to specify the parameter by adding df=text in the URL.

Thank you for updating the wiki page on the surround parser:
http://wiki.apache.org/solr/SurroundQueryParser

Hopefully, ordered proximity searches will be supported in the edismax query 
parser itself as the surround query parser is not as good as the edismax 
parser: https://issues.apache.org/jira/browse/SOLR-3101
Is there a way to AND the surround parser query with the edismax query so the 
ordered proximity search can be run through the surround query parser and the 
results combined/queried with the edismax query parser for other parts of the 
query? Can nested queries support this?

Thanks,
Niran


Niran -

Looks like you're being bitten by a known feature* of the surround query 
parser.  It does not analyze the text, as some of the other more commonly used 
query parsers does.  The dismax, edismax, and lucene query parsers all 
leverage field analysis on the query terms or phrases. The surround query 
parser just takes the terms as-is.  It's by design, but not necessarily 
something that can't at least be optionally available.  But as it is, you'll 
need to lowercase, at least.  Be careful with index-time stemming, as you'd 
have to account for that in the surround query parser syntax by wildcarding 
things a bit.  Instead of searching for finding, one would use find* (and 
index without stemming) in the query to match finds, finding.  It was by 
design to not analyze in the surround query parser because it can be handy to 
use less analysis tricks at index time, and let the query itself be more 
sophisticated to allow more flexible and indeed more complex query-time 
constructs.

Erik

* http://wiki.apache.org/solr/SurroundQueryParser#Limitations - though it'd be 
useful to have analysis at least optionally available.

Re: Surround query parser not working?

[Jack Krupansky]

Yes, you should be able to used nested query parsers to mix the queries. 
Solr 4.1(?) made it easier.


-- Jack Krupansky

-Original Message- 
From: Abeygunawardena, Niran

Sent: Monday, July 08, 2013 7:00 AM
To: solr-user@lucene.apache.org
Subject: Re: Surround query parser not working?

Hi,

Thanks. I found out that my issue was the default field (df) was being 
ignored and I had to specify the parameter by adding df=text in the URL.


Thank you for updating the wiki page on the surround parser:
http://wiki.apache.org/solr/SurroundQueryParser

Hopefully, ordered proximity searches will be supported in the edismax query 
parser itself as the surround query parser is not as good as the edismax 
parser: https://issues.apache.org/jira/browse/SOLR-3101
Is there a way to AND the surround parser query with the edismax query so 
the ordered proximity search can be run through the surround query parser 
and the results combined/queried with the edismax query parser for other 
parts of the query? Can nested queries support this?


Thanks,
Niran


Niran -

Looks like you're being bitten by a known feature* of the surround query 
parser.  It does not analyze the text, as some of the other more commonly 
used query parsers does.  The dismax, edismax, and lucene query parsers 
all leverage field analysis on the query terms or phrases. The surround 
query parser just takes the terms as-is.  It's by design, but not 
necessarily something that can't at least be optionally available.  But as 
it is, you'll need to lowercase, at least.  Be careful with index-time 
stemming, as you'd have to account for that in the surround query parser 
syntax by wildcarding things a bit.  Instead of searching for finding, one 
would use find* (and index without stemming) in the query to match 
finds, finding.  It was by design to not analyze in the surround query 
parser because it can be handy to use less analysis tricks at index time, 
and let the query itself be more sophisticated to allow more flexible and 
indeed more complex query-time constructs.


   Erik

* http://wiki.apache.org/solr/SurroundQueryParser#Limitations - though it'd 
be useful to have analysis at least optionally available.

Surround query parser not working?

[Abeygunawardena, Niran]

Hi,

I have tried to get the surround query parser working against SOLR 4.3.0 and 
SOLR 4.0.0 but it does not seem to return any documents for me. I need this 
parser to make ordered proximity searches with the operator W. I have tried 
the parser with normal boolean operators like OR and it still does not work for 
me. What am I doing wrong?

My example queries:
http://localhost:8983/solr/reference_core/keyword?q={!surround}Wuthering+OR+Heightsdebug=truehttp://localhost:8983/solr/reference_core/keyword?q=%7b!surround%7dWuthering+OR+Heightsdebug=true
http://localhost:8983/solr/reference_core/keyword?q=Wuthering+OR+Heightsdebug=truedefType=surround
The response I get from the above queries:
response
lst name=responseHeader
int name=status0/int
int name=QTime1/int
lst name=params
str name=q{!surround}Wuthering OR Heights/str
str name=debugtrue/str
/lst
/lst
result name=response numFound=0 start=0/
lst name=debug
str name=rawquerystring{!surround}Wuthering OR Heights/str
str name=querystring{!surround}Wuthering OR Heights/str
str name=parsedquery
SimpleTermRewriteQuery(org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(text,
 Wuthering, 
org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries: 
1000, queriesMade: 0)))

SimpleTermRewriteQuery(org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(text,
 Heights, 
org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries: 
1000, queriesMade: 0)))
/str
str name=parsedquery_toString
org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(unused: 
)(text, Wuthering, 
org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries: 
1000, queriesMade: 0))
org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(unused: 
)(text, Heights, 
org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries: 
1000, queriesMade: 0))
/str
lst name=explain/
str name=QParserSurroundQParser/str
lst name=timing/lst
/lst
/response


Whereas the same query against the edismax query parser, I get back 756 docs:
http://localhost:8983/solr/reference_core/keyword?q=Wuthering+OR+Heightsdebug=true
response
lst name=responseHeader
int name=status0/int
int name=QTime39/int
lst name=params
str name=qWuthering OR Heights/str
str name=debugtrue/str
/lst
/lst
result name=response numFound=756 start=0/result
lst name=debug
str name=rawquerystringWuthering OR Heights/str
str name=querystringWuthering OR Heights/str
str name=parsedquery
(+(DisjunctionMaxQuery((biobrand:wuther | ilcs_biog:wuther |)))/no_coord
/str
str name=parsedquery_toString
+((biobrand:wuther | ilcs_biog:wuther | comhd0:wuther | ))
/str
lst name=explain/lst
str name=QParserExtendedDismaxQParser/str
null name=altquerystring/
null name=boost_queries/
arr name=parsed_boost_queries/
null name=boostfuncs/
lst name=timing/lst
/lst
/response



Any help is much appreciated.

Thanks,
Niran

Re: Surround query parser not working?

[Erik Hatcher]

Niran -

Looks like you're being bitten by a known feature* of the surround query 
parser.  It does not analyze the text, as some of the other more commonly used 
query parsers does.  The dismax, edismax, and lucene query parsers all 
leverage field analysis on the query terms or phrases.  The surround query 
parser just takes the terms as-is.  It's by design, but not necessarily 
something that can't at least be optionally available.  But as it is, you'll 
need to lowercase, at least.  Be careful with index-time stemming, as you'd 
have to account for that in the surround query parser syntax by wildcarding 
things a bit.  Instead of searching for finding, one would use find* (and 
index without stemming) in the query to match finds, finding.  It was by 
design to not analyze in the surround query parser because it can be handy to 
use less analysis tricks at index time, and let the query itself be more 
sophisticated to allow more flexible and indeed more complex query-time 
constructs.

Erik

* http://wiki.apache.org/solr/SurroundQueryParser#Limitations - though it'd be 
useful to have analysis at least optionally available.


On Jul 3, 2013, at 07:42 , Abeygunawardena, Niran wrote:

 Hi,
 
 I have tried to get the surround query parser working against SOLR 4.3.0 and 
 SOLR 4.0.0 but it does not seem to return any documents for me. I need this 
 parser to make ordered proximity searches with the operator W. I have tried 
 the parser with normal boolean operators like OR and it still does not work 
 for me. What am I doing wrong?
 
 My example queries:
 http://localhost:8983/solr/reference_core/keyword?q={!surround}Wuthering+OR+Heightsdebug=truehttp://localhost:8983/solr/reference_core/keyword?q=%7b!surround%7dWuthering+OR+Heightsdebug=true
 http://localhost:8983/solr/reference_core/keyword?q=Wuthering+OR+Heightsdebug=truedefType=surround
 The response I get from the above queries:
 response
 lst name=responseHeader
 int name=status0/int
 int name=QTime1/int
 lst name=params
 str name=q{!surround}Wuthering OR Heights/str
 str name=debugtrue/str
 /lst
 /lst
 result name=response numFound=0 start=0/
 lst name=debug
 str name=rawquerystring{!surround}Wuthering OR Heights/str
 str name=querystring{!surround}Wuthering OR Heights/str
 str name=parsedquery
 SimpleTermRewriteQuery(org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(text,
  Wuthering, 
 org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries:
  1000, queriesMade: 0)))

 SimpleTermRewriteQuery(org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(text,
  Heights, 
 org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries:
  1000, queriesMade: 0)))
 /str
 str name=parsedquery_toString
 org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(unused: 
 )(text, Wuthering, 
 org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries:
  1000, queriesMade: 0))
 org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(unused: 
 )(text, Heights, 
 org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries:
  1000, queriesMade: 0))
 /str
 lst name=explain/
 str name=QParserSurroundQParser/str
 lst name=timing/lst
 /lst
 /response
 
 
 Whereas the same query against the edismax query parser, I get back 756 docs:
 http://localhost:8983/solr/reference_core/keyword?q=Wuthering+OR+Heightsdebug=true
 response
 lst name=responseHeader
 int name=status0/int
 int name=QTime39/int
 lst name=params
 str name=qWuthering OR Heights/str
 str name=debugtrue/str
 /lst
 /lst
 result name=response numFound=756 start=0/result
 lst name=debug
 str name=rawquerystringWuthering OR Heights/str
 str name=querystringWuthering OR Heights/str
 str name=parsedquery
 (+(DisjunctionMaxQuery((biobrand:wuther | ilcs_biog:wuther |)))/no_coord
 /str
 str name=parsedquery_toString
 +((biobrand:wuther | ilcs_biog:wuther | comhd0:wuther | ))
 /str
 lst name=explain/lst
 str name=QParserExtendedDismaxQParser/str
 null name=altquerystring/
 null name=boost_queries/
 arr name=parsed_boost_queries/
 null name=boostfuncs/
 lst name=timing/lst
 /lst
 /response
 
 
 
 Any help is much appreciated.
 
 Thanks,
 Niran
 

Re: Surround query parser not working?

[Ahmet Arslan]

Hi Niran,

No analysis is done with surround. For example if you have lowercase filter in 
your index analysis chain then 'Wuthering OR Heights' won't match. Try using 
'wuthering OR heights'.  Stemming can be problematic in this too.

See limitations in http://wiki.apache.org/solr/SurroundQueryParser

Ahmet


 From: Abeygunawardena, Niran niran.abeygunaward...@proquest.co.uk
To: solr-user@lucene.apache.org solr-user@lucene.apache.org 
Sent: Wednesday, July 3, 2013 2:42 PM
Subject: Surround query parser not working?
 

Hi,

I have tried to get the surround query parser working against SOLR 4.3.0 and 
SOLR 4.0.0 but it does not seem to return any documents for me. I need this 
parser to make ordered proximity searches with the operator W. I have tried 
the parser with normal boolean operators like OR and it still does not work for 
me. What am I doing wrong?

My example queries:
http://localhost:8983/solr/reference_core/keyword?q={!surround}Wuthering+OR+Heightsdebug=truehttp://localhost:8983/solr/reference_core/keyword?q=%7b!surround%7dWuthering+OR+Heightsdebug=true
http://localhost:8983/solr/reference_core/keyword?q=Wuthering+OR+Heightsdebug=truedefType=surround
The response I get from the above queries:
response
lst name=responseHeader
int name=status0/int
int name=QTime1/int
lst name=params
str name=q{!surround}Wuthering OR Heights/str
str name=debugtrue/str
/lst
/lst
result name=response numFound=0 start=0/
lst name=debug
str name=rawquerystring{!surround}Wuthering OR Heights/str
str name=querystring{!surround}Wuthering OR Heights/str
str name=parsedquery
SimpleTermRewriteQuery(org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(text,
 Wuthering, 
org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries: 
1000, queriesMade: 0)))
                
SimpleTermRewriteQuery(org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(text,
 Heights, 
org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries: 
1000, queriesMade: 0)))
/str
str name=parsedquery_toString
org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(unused: 
)(text, Wuthering, 
org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries: 
1000, queriesMade: 0))
org.apache.lucene.queryparser.surround.query.SimpleTermRewriteQuery(unused: 
)(text, Heights, 
org.apache.lucene.queryparser.surround.query.BasicQueryFactory(maxBasicQueries: 
1000, queriesMade: 0))
/str
lst name=explain/
str name=QParserSurroundQParser/str
lst name=timing/lst
/lst
/response


Whereas the same query against the edismax query parser, I get back 756 docs:
http://localhost:8983/solr/reference_core/keyword?q=Wuthering+OR+Heightsdebug=true
response
lst name=responseHeader
int name=status0/int
int name=QTime39/int
lst name=params
str name=qWuthering OR Heights/str
str name=debugtrue/str
/lst
/lst
result name=response numFound=756 start=0/result
lst name=debug
str name=rawquerystringWuthering OR Heights/str
str name=querystringWuthering OR Heights/str
str name=parsedquery
(+(DisjunctionMaxQuery((biobrand:wuther | ilcs_biog:wuther |)))/no_coord
/str
str name=parsedquery_toString
+((biobrand:wuther | ilcs_biog:wuther | comhd0:wuther | ))
/str
lst name=explain/lst
str name=QParserExtendedDismaxQParser/str
null name=altquerystring/
null name=boost_queries/
arr name=parsed_boost_queries/
null name=boostfuncs/
lst name=timing/lst
/lst
/response



Any help is much appreciated.

Thanks,
Niran

Re: Surround query parser not working?

[Roman Chyla]

Hi Niran, all,
Please look at JIRA LUCENE-5014. There you will find a Lucene parser that
does both analysis and span queries, equivalent to combination of
lucene+surround, and much more The ticket needs your review.

Roman

Re: Surround query parser not working?

[Erik Hatcher]

Indeed, Roman.  Thanks for mentioning that.  I just took a quick look at that 
issue and will look at it even deeper as time permits.

Erik

On Jul 3, 2013, at 09:43 , Roman Chyla wrote:

 Hi Niran, all,
 Please look at JIRA LUCENE-5014. There you will find a Lucene parser that
 does both analysis and span queries, equivalent to combination of
 lucene+surround, and much more The ticket needs your review.
 
 Roman