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.
