If I understand you guys correct If I have term which has n tokens I will need to create n SpanTermQuery put them in array and pass it to SpanNearQuery?
Erik Hatcher wrote: > > > On Apr 12, 2009, at 8:15 AM, Tim Williams wrote: > >> On Sun, Apr 12, 2009 at 5:56 AM, Erik Hatcher >> <e...@ehatchersolutions.com> wrote: >>> >>> On Apr 11, 2009, at 9:11 PM, Tim Williams wrote: >>> >>>> On Sat, Apr 11, 2009 at 12:25 PM, Erick Erickson >>>> <erickerick...@gmail.com> wrote: >>>>> >>>>> That'll teach me to scan a post. The link I sent you >>>>> is still relevant, but wildcards are NOT intended to be used to >>>>> concatenate terms. You want a phrase query or a span query >>>>> for that. i.e. "A C F"~# where # is the "slop", that is, the number >>>>> of other terms allowed to appear between your desired terms. >>>>> >>>>> SpanQueries are constructed programmatically, and PhraseQueries >>>>> are produced by the parser. >>>> >>>> As I understand it though, there's no way to use the queryparser to >>>> construct an *ordered* phrase query with slop (which is what I think >>>> he's after), right? I gather that'd have to be done manually with a >>>> SpanNearQuery. I'd love to hear that the query parser has syntax >>>> for >>>> this though... >>> >>> QueryParser does not create any SpanQuery's, but one can subclass >>> QueryParser and override getFieldQuery() to put in a SpanQuery >>> instead of a >>> PhraseQuery. >> >> Thanks Erik, wouldn't this be an all-or-nothing replacement though? >> In other words, by creating ordered SpanNearQuery's as the override, >> wouldn't he loose the current unordered PhraseQuery+slop >> functionality? I haven't seen a way to subclass the QueryParser to >> support both (e.g. extend the syntax)? > > As always, it depends. If the QueryParser subclass has a switch to > toggle between SpanNearQuery and PhraseQuery it could controlled by > the code which way to go. But yeah, it's not currently possible to > extend the syntax of QueryParser with a subclass. There is a nice new > open issue with a new query parser implementation that is vastly more > flexible - we'll see that come in to Lucene in the near future. > > Erik > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > -- View this message in context: http://www.nabble.com/Sequential-match-query-tp22995240p23026389.html Sent from the Lucene - Java Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
