Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <B11F01AC-AFD7-4D87-9CCF-E59CB9373D70@ehatchersolutions.com>
From: Erik Hatcher <erik@ehatchersolutions.com>
To: java-user@lucene.apache.org
In-Reply-To: <499888440904120515t7f7516a1m81615f4b56db3c29@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Sequential match query
Date: Sun, 12 Apr 2009 09:30:43 -0400
References: <22995240.post@talk.nabble.com>
 <359a92830904110925m24dda294l343ad947acb3ea43@mail.gmail.com>
 <499888440904111811j34e4bf3clab0de3a176215363@mail.gmail.com>
 <07E17CDF-6BA8-4919-BD23-AA81351ABC01@ehatchersolutions.com>
 <499888440904120515t7f7516a1m81615f4b56db3c29@mail.gmail.com>


On Apr 12, 2009, at 8:15 AM, Tim Williams wrote:

> On Sun, Apr 12, 2009 at 5:56 AM, Erik Hatcher
> <erik@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
>>> <erickerickson@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org