Re: SpellingQueryConverter and query parsing

[Scott Stults]

Thank you, James, I'll do that.

ResponseBuilder carries around with it the QParser, Query, and query
string, so getting suggestions from parsed query terms shouldn't be a big
deal. What looks to be hard is rewriting the original query with the
suggestions. That's probably why the regex is used instead of the parser.

-Scott

On Tue, Jan 27, 2015 at 1:37 PM, Dyer, James james.d...@ingramcontent.com
wrote:

 Having worked with the spellchecking code for the last few years, I've
 often wondered the same thing, but I never looked seriously into it.  I'm
 sure there's probably some serious hurdles, hence the Query Converter.  The
 easy thing to do here is to use spellcheck.q, and then pass in
 space-delimited keywords.  This bypasses the query converter entirely for
 custom situations like yours.

 But please, if you find a way to plug the actual query parser into
 spellcheck, consider opening a jira  contributing the code, even if what
 you end up with isn't in a final polished state for general use.

 James Dyer
 Ingram Content Group


 -Original Message-
 From: Scott Stults [mailto:sstu...@opensourceconnections.com]
 Sent: Tuesday, January 27, 2015 11:26 AM
 To: solr-user@lucene.apache.org
 Subject: SpellingQueryConverter and query parsing

 Hello!

 SpellingQueryConverter parses the incoming query in sort of a quick and
 dirty way with a regular expression. Is there a reason the query string
 isn't parsed with the _actual_ parser, if one was configured for that type
 of request? Even better, could the parsed query object be added to the
 response in some way so that the query wouldn't need to be parsed twice?
 The individual terms could then be visited and substituted in-place without
 needing to worry about preserving the meaning of operators in the query.

 The motive in my question is, I may need to implement a QueryConverter
 because I'm using a custom parser, and using that parser in the
 QueryConverter itself seems like the right thing to do. That wasn't done
 though in SpellingQueryConverter, so I wan't to find out why before I go
 blundering into a known minefield.


 Thanks!
 -Scott




-- 
Scott Stults | Founder  Solutions Architect | OpenSource Connections, LLC
| 434.409.2780
http://www.opensourceconnections.com

RE: SpellingQueryConverter and query parsing

[Dyer, James]

Having worked with the spellchecking code for the last few years, I've often 
wondered the same thing, but I never looked seriously into it.  I'm sure 
there's probably some serious hurdles, hence the Query Converter.  The easy 
thing to do here is to use spellcheck.q, and then pass in space-delimited 
keywords.  This bypasses the query converter entirely for custom situations 
like yours.

But please, if you find a way to plug the actual query parser into spellcheck, 
consider opening a jira  contributing the code, even if what you end up with 
isn't in a final polished state for general use.

James Dyer
Ingram Content Group


-Original Message-
From: Scott Stults [mailto:sstu...@opensourceconnections.com]
Sent: Tuesday, January 27, 2015 11:26 AM
To: solr-user@lucene.apache.org
Subject: SpellingQueryConverter and query parsing

Hello!

SpellingQueryConverter parses the incoming query in sort of a quick and
dirty way with a regular expression. Is there a reason the query string
isn't parsed with the _actual_ parser, if one was configured for that type
of request? Even better, could the parsed query object be added to the
response in some way so that the query wouldn't need to be parsed twice?
The individual terms could then be visited and substituted in-place without
needing to worry about preserving the meaning of operators in the query.

The motive in my question is, I may need to implement a QueryConverter
because I'm using a custom parser, and using that parser in the
QueryConverter itself seems like the right thing to do. That wasn't done
though in SpellingQueryConverter, so I wan't to find out why before I go
blundering into a known minefield.


Thanks!
-Scott