Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <786fde50908080110m2673346fx471dce14bd758f76@mail.gmail.com>
References: <57062352-8173-4023-95AA-CA24C902C13A@apache.org>
	 <D145058C-D844-4669-99F7-2EA37AE8BFA5@apache.org>
	 <200908062031.40321.paul.elschot@xs4all.nl>
	 <7CEB9EAF-8FB2-4502-A06A-7D3051B03080@apache.org>
	 <786fde50908061325q5b00ab54x3c00c0b4ce452bf4@mail.gmail.com>
	 <BD48DF46-EEE0-401B-A2C9-4A9498F2B7A0@apache.org>
	 <786fde50908061406j76723b97v15b6822e01cc6f4c@mail.gmail.com>
	 <B3FE9DCD-1F7E-47B9-B6E1-873C6FD20A46@apache.org>
	 <EF650CE3-7948-4120-8AD0-FE9F2C8B35D7@apache.org>
	 <786fde50908080110m2673346fx471dce14bd758f76@mail.gmail.com>
Date: Wed, 12 Aug 2009 05:58:13 -0400
Message-ID: <9ac0c6aa0908120258r6a8c83ffu7d52ee3b2f7dd5ba@mail.gmail.com>
Subject: Re: SpanQuery and Spans optimizations
From: Michael McCandless <lucene@mikemccandless.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think being able to ask the Scorer for matching spans for the
current doc makes tons of sense.

I think eventually span queries should be absorbed into the normal
lucene queries.  EG, if TermQuery creates a scorer that's able to
optionally enumerate matching spans, such that there's no performance
loss if you don't actuallly request the spans, then we don't need
SpanTermQuery.

And once all Lucene queries can optionally provide their spans, then
highlighter becomes simpler since it can just ask the query's scorer
for the matching spans.

Mike

On Sat, Aug 8, 2009 at 4:10 AM, Shai Erera<serera@gmail.com> wrote:
> That would work. Though your custom TopSpansCollector should be able to
> handle other Scorers as well. And you can store the payloads in yet anoth=
er
> custom ScoreDoc - is that what you had in mind?
>
> Shai
>
> On Sat, Aug 8, 2009 at 3:06 AM, Grant Ingersoll <gsingers@apache.org> wro=
te:
>>
>> On Aug 6, 2009, at 5:09 PM, Grant Ingersoll wrote:
>>
>>>
>>> On Aug 6, 2009, at 5:06 PM, Shai Erera wrote:
>>>
>>>> Only w/ ScoreDocs we reuse the same instance. So I guess we'd like to =
do
>>>> the same here.
>>>>
>>>> Seems like providing a TopSpansCollector is what you want, only unlike
>>>> TopFieldCollector which populates the fields post search, you'd like t=
o do
>>>> it during search.
>>>
>>> Bingo, but I think the collection functionality needs to be on Collecto=
r,
>>> as I'd hate to have to lose out on functionality that the other impls h=
ave
>>> to offer, or have to recreate them.
>>>
>>
>> Hmm, maybe I can get at this info from the setScorer capabilities. =A0Th=
en I
>> would just need a place to hang the data... =A0Maybe would just take hav=
ing
>> the SpanScorer implementation provide just a wee bit more access to
>> structures...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org