Mailing List Archive: Lucene: Java-User

Extending Sort/FieldCache

Index | Next | Previous | View Threaded

serera at gmail

Aug 20, 2009, 4:49 AM

Post #1 of 13 (2162 views)
Permalink

Extending Sort/FieldCache

Hi

I'd like to extend Lucene's FieldCache such that it will read native values
from a different place (in my case, payloads). That is, instead of iterating
on a field's terms and parsing each String to long (for example), I'd like
to iterate over one term (sort:long, again - an example) and decode each
payload value to long, and store it in the cache. The reason I want to
extend Lucene's FieldCache is because I'd like Lucene to take care of
updating this cache when necessary (such as after reopen for example). This
will allow me to use Lucene's Sort option more easily.

I noticed Sort can be extended by providing a CUSTOM SortField, but that
forces me to create Comparable objects, which is much more expensive than
native longs (40 bytes vs. 8 bytes).

I didn't find a way though to extend FieldCache, or ExtendedFieldCache -->
even though both are extendable, I don't find the place where they're given
as input to TopFieldDocCollector, FieldSortedHitQueue etc. Perhaps I'm
missing it?

I need to do it on top of 2.4.1, but if it's not possible and something was
done in 2.9 (which I missed) in that regard I'd be happy to get a pointer to
that.

Today, I use this payload to implement sorting, which is memory efficient
for very large indexes, but for small indexes I think Lucene's built-in sort
will perform better.

BTW, if it interests anyone, perhaps augmenting Lucene's sort w/ reading
values from a Payload, or doing a complete payload-based-sort, I can work up
a patch ...

Thanks
Shai

hossman_lucene at fucit

Aug 25, 2009, 10:36 AM

Post #2 of 13 (2059 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

: I'd like to extend Lucene's FieldCache such that it will read native values
...
: payload value to long, and store it in the cache. The reason I want to
: extend Lucene's FieldCache is because I'd like Lucene to take care of
: updating this cache when necessary (such as after reopen for example). This
: will allow me to use Lucene's Sort option more easily.

this was my motivation when i opened LUCENE-831, but i promptly got bogged
down with other shit and had to abandon that issue ...
Miller/Uwe/McCandles seemed like they were making really cool progress
with it, but (if i remember correctly) it seems to have gotten into some
sort of quagmire related to reopen and segment merging -- which led to a
lot of the current segment based sortinging we have now, which makes most
of that issue obsolete.

but we still have hte issue of wanting to provide your own caching
mechanism -- which at the moment has no solution that i know of.

: I noticed Sort can be extended by providing a CUSTOM SortField, but that

i think you're only option is to use a custom Sort which uses your own
private cache of some kind.

: I didn't find a way though to extend FieldCache, or ExtendedFieldCache -->
: even though both are extendable, I don't find the place where they're given
: as input to TopFieldDocCollector, FieldSortedHitQueue etc. Perhaps I'm
: missing it?

you're not missing anything ... a singleton is used, and you can't replace
the singlton because its' a static on the Interface.

: BTW, if it interests anyone, perhaps augmenting Lucene's sort w/ reading
: values from a Payload, or doing a complete payload-based-sort, I can work up
: a patch ...

I believe that was always one of Busch's goals with the payload stuff, but
last time i remember hearing about it he was thinking that rather then
doing it directly with payloads he wants to skip ahead to use column-stride
fields ... not sure if he had an implementation in mind yet though.

-Hoss

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

serera at gmail

Aug 26, 2009, 8:31 PM

Post #3 of 13 (2047 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

Thanks a lot for the response !

I wanted to avoid two things:
* Writing the logic that invokes cache-refresh upon IndexReader reload.
* Write my own TopFieldCollector which uses this cache.

I guess I don't have any other choice by to write both of them, or try to
make TFC more "customizable" such that someone can pass in his own
FieldCachePQ. I'll start w/ my own version and if possible suggest an
extension to TFC.

Thanks again,
Shai

On Tue, Aug 25, 2009 at 8:36 PM, Chris Hostetter
<hossman_lucene [at] fucit>wrote:

>
> : I'd like to extend Lucene's FieldCache such that it will read native
> values
> ...
> : payload value to long, and store it in the cache. The reason I want to
> : extend Lucene's FieldCache is because I'd like Lucene to take care of
> : updating this cache when necessary (such as after reopen for example).
> This
> : will allow me to use Lucene's Sort option more easily.
>
> this was my motivation when i opened LUCENE-831, but i promptly got bogged
> down with other shit and had to abandon that issue ...
> Miller/Uwe/McCandles seemed like they were making really cool progress
> with it, but (if i remember correctly) it seems to have gotten into some
> sort of quagmire related to reopen and segment merging -- which led to a
> lot of the current segment based sortinging we have now, which makes most
> of that issue obsolete.
>
> but we still have hte issue of wanting to provide your own caching
> mechanism -- which at the moment has no solution that i know of.
>
> : I noticed Sort can be extended by providing a CUSTOM SortField, but that
>
> i think you're only option is to use a custom Sort which uses your own
> private cache of some kind.
>
> : I didn't find a way though to extend FieldCache, or ExtendedFieldCache
> -->
> : even though both are extendable, I don't find the place where they're
> given
> : as input to TopFieldDocCollector, FieldSortedHitQueue etc. Perhaps I'm
> : missing it?
>
> you're not missing anything ... a singleton is used, and you can't replace
> the singlton because its' a static on the Interface.
>
> : BTW, if it interests anyone, perhaps augmenting Lucene's sort w/ reading
> : values from a Payload, or doing a complete payload-based-sort, I can work
> up
> : a patch ...
>
> I believe that was always one of Busch's goals with the payload stuff, but
> last time i remember hearing about it he was thinking that rather then
> doing it directly with payloads he wants to skip ahead to use column-stride
> fields ... not sure if he had an implementation in mind yet though.
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

serera at gmail

Sep 3, 2009, 9:33 PM

Post #4 of 13 (1978 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

Thanks

I plan to look into two things, and then probably create two separate
issues:

1) Refactor the FieldCache API (and TopFieldCollector) such that one can
provide its own Cache of native values. I'd hate to rewrite the
FieldComparators logic just because the current API is not extendable. That
I agree should be quite straightforward, but I'll need to look into it
first.

2) Contribute my payload-based sorting package. Currently it only reads from
disk during searches, and I'd like to enhance it to use in-memory cache as
well. It's a moderate-size package, so this one will need to wait until (1)
is done, and I get enough time to adapt it to 2.9 and work on the issue.

I definitely don't think this should be a 2.9 sort of work, unless someone
else volunteers to do it. I can't pull (1) together that quickly.

I thought that FieldCache is loaded when the IndexReader is reopened no? I
mean, it's a per IndexReader instance no? If not, then I'll need to rethink
the entire approach, because then (1) may not be that important anymore.

Shai

On Fri, Sep 4, 2009 at 1:15 AM, Chris Hostetter <hossman_lucene [at] fucit>wrote:

>
> : I wanted to avoid two things:
> : * Writing the logic that invokes cache-refresh upon IndexReader reload.
>
> Uh... i don't think there is any code that FieldCache refreshing on
> reload (yet), so you wouldn't be missing out on anything. (as long as
> your custom cache works at the SegmentReader level, you'd have the exact
> same benefits as using FieldCache)
>
> : * Write my own TopFieldCollector which uses this cache.
>
> well, yeah ... there you're screwed.
>
> you know ... just because FieldCache.DEFAULT is a static final singleton,
> doesn't mean we need to have FieldCache.DEFAULT hardcoded in so many
> places ... a lot of the high level classes that refer to
> FieldCache.DEFAULT could probably be refacotred to have a
> setFieldCache(FieldCache) method that defaults to FieldCache.DEFAULT, and
> then they could pass it down to the lower level classes ... that way you
> *could* write a "MyFieldCache extends FieldCache", and then have a
> SortComparator (or FieldComparator, or whatever it's called now) that cast
> the FieldCache it gets to your MyFieldCache and calls the custom methods
> ... withoutneeding to rewrite all of hte Collector code.
>
> It sounds a little invasive to make it into 2.9 ... but i haven't looked
> ito what it would involve ... in theory it could be really straight
> forward and backwards compatible.
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

lucene at mikemccandless

Sep 4, 2009, 2:17 AM

Post #5 of 13 (1969 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

On Fri, Sep 4, 2009 at 12:33 AM, Shai Erera<serera [at] gmail> wrote:

> 1) Refactor the FieldCache API (and TopFieldCollector) such that one can
> provide its own Cache of native values. I'd hate to rewrite the
> FieldComparators logic just because the current API is not extendable. That
> I agree should be quite straightforward, but I'll need to look into it
> first.

+1

Or, so that the current consumers of FieldCache (that hardwire to
FieldCache.DEFAULT) could simply accept any other FieldCache
instance, as Hoss suggested.

> 2) Contribute my payload-based sorting package. Currently it only reads from
> disk during searches, and I'd like to enhance it to use in-memory cache as
> well. It's a moderate-size package, so this one will need to wait until (1)
> is done, and I get enough time to adapt it to 2.9 and work on the issue.

+1, sounds cool!

> I definitely don't think this should be a 2.9 sort of work, unless someone
> else volunteers to do it. I can't pull (1) together that quickly.

Me too... 2.9 train is moving out of the station now!

> I thought that FieldCache is loaded when the IndexReader is reopened no? I
> mean, it's a per IndexReader instance no? If not, then I'll need to rethink
> the entire approach, because then (1) may not be that important anymore.

FieldCache is only opened on demand, ie, the first time that a newly
opened reader calls FieldCache.DEFAULT.getXXX does it get populated.

So it's not during the reopen... it's during the first query that eg sorts
by a field.

It'd be great if your use case gives us enough clarity on LUCENE-831
to make concrete progress.

Note that function queries already "wrap" FieldCache w/ an alternate API
for native value per doc (ValueSource, DocValues, FieldCacheSource),
that do allow custom ValueSources to be provided. It'd be great if
as part of LUCENE-831 they could be more unified w/ FieldCache's
API.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

serera at gmail

Sep 4, 2009, 9:19 AM

Post #6 of 13 (1977 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

Thanks Mike. I did not phrase well my understanding of Cache reload. I
didn't mean literally as part of the reopen, but *because* of the reopen.
Because FieldCache is tied to an IndexReader instance, after reopen it gets
refreshed. If I keep my own Cache, I'll need to code that logic, and I
prefer to use what's currently in Lucene. (Sloth? :) )

I'll look at the mentioned function queries. Thanks for the pointer !

Shai
On Fri, Sep 4, 2009 at 12:17 PM, Michael McCandless <
lucene [at] mikemccandless> wrote:

> On Fri, Sep 4, 2009 at 12:33 AM, Shai Erera<serera [at] gmail> wrote:
>
> > 1) Refactor the FieldCache API (and TopFieldCollector) such that one can
> > provide its own Cache of native values. I'd hate to rewrite the
> > FieldComparators logic just because the current API is not extendable.
> That
> > I agree should be quite straightforward, but I'll need to look into it
> > first.
>
> +1
>
> Or, so that the current consumers of FieldCache (that hardwire to
> FieldCache.DEFAULT) could simply accept any other FieldCache
> instance, as Hoss suggested.
>
> > 2) Contribute my payload-based sorting package. Currently it only reads
> from
> > disk during searches, and I'd like to enhance it to use in-memory cache
> as
> > well. It's a moderate-size package, so this one will need to wait until
> (1)
> > is done, and I get enough time to adapt it to 2.9 and work on the issue.
>
> +1, sounds cool!
>
> > I definitely don't think this should be a 2.9 sort of work, unless
> someone
> > else volunteers to do it. I can't pull (1) together that quickly.
>
> Me too... 2.9 train is moving out of the station now!
>
> > I thought that FieldCache is loaded when the IndexReader is reopened no?
> I
> > mean, it's a per IndexReader instance no? If not, then I'll need to
> rethink
> > the entire approach, because then (1) may not be that important anymore.
>
> FieldCache is only opened on demand, ie, the first time that a newly
> opened reader calls FieldCache.DEFAULT.getXXX does it get populated.
>
> So it's not during the reopen... it's during the first query that eg sorts
> by a field.
>
> It'd be great if your use case gives us enough clarity on LUCENE-831
> to make concrete progress.
>
> Note that function queries already "wrap" FieldCache w/ an alternate API
> for native value per doc (ValueSource, DocValues, FieldCacheSource),
> that do allow custom ValueSources to be provided. It'd be great if
> as part of LUCENE-831 they could be more unified w/ FieldCache's
> API.
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

erickerickson at gmail

Sep 4, 2009, 5:52 PM

Post #7 of 13 (1957 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

No, not sloth. Making use of the fine work that others have done in
order to help get your product out the door faster/cheaper <G>....

As in "There's no virtue in re-inventing the wheel. No matter how
productive it feels" <GGGG>.

Best
Erick

On Fri, Sep 4, 2009 at 12:19 PM, Shai Erera <serera [at] gmail> wrote:

> Thanks Mike. I did not phrase well my understanding of Cache reload. I
> didn't mean literally as part of the reopen, but *because* of the reopen.
> Because FieldCache is tied to an IndexReader instance, after reopen it gets
> refreshed. If I keep my own Cache, I'll need to code that logic, and I
> prefer to use what's currently in Lucene. (Sloth? :) )
>
> I'll look at the mentioned function queries. Thanks for the pointer !
>
> Shai
> On Fri, Sep 4, 2009 at 12:17 PM, Michael McCandless <
> lucene [at] mikemccandless> wrote:
>
> > On Fri, Sep 4, 2009 at 12:33 AM, Shai Erera<serera [at] gmail> wrote:
> >
> > > 1) Refactor the FieldCache API (and TopFieldCollector) such that one
> can
> > > provide its own Cache of native values. I'd hate to rewrite the
> > > FieldComparators logic just because the current API is not extendable.
> > That
> > > I agree should be quite straightforward, but I'll need to look into it
> > > first.
> >
> > +1
> >
> > Or, so that the current consumers of FieldCache (that hardwire to
> > FieldCache.DEFAULT) could simply accept any other FieldCache
> > instance, as Hoss suggested.
> >
> > > 2) Contribute my payload-based sorting package. Currently it only reads
> > from
> > > disk during searches, and I'd like to enhance it to use in-memory cache
> > as
> > > well. It's a moderate-size package, so this one will need to wait until
> > (1)
> > > is done, and I get enough time to adapt it to 2.9 and work on the
> issue.
> >
> > +1, sounds cool!
> >
> > > I definitely don't think this should be a 2.9 sort of work, unless
> > someone
> > > else volunteers to do it. I can't pull (1) together that quickly.
> >
> > Me too... 2.9 train is moving out of the station now!
> >
> > > I thought that FieldCache is loaded when the IndexReader is reopened
> no?
> > I
> > > mean, it's a per IndexReader instance no? If not, then I'll need to
> > rethink
> > > the entire approach, because then (1) may not be that important
> anymore.
> >
> > FieldCache is only opened on demand, ie, the first time that a newly
> > opened reader calls FieldCache.DEFAULT.getXXX does it get populated.
> >
> > So it's not during the reopen... it's during the first query that eg
> sorts
> > by a field.
> >
> > It'd be great if your use case gives us enough clarity on LUCENE-831
> > to make concrete progress.
> >
> > Note that function queries already "wrap" FieldCache w/ an alternate API
> > for native value per doc (ValueSource, DocValues, FieldCacheSource),
> > that do allow custom ValueSources to be provided. It'd be great if
> > as part of LUCENE-831 they could be more unified w/ FieldCache's
> > API.
> >
> > Mike
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> > For additional commands, e-mail: java-user-help [at] lucene
> >
> >
>

yonik at lucidimagination

Sep 5, 2009, 8:45 AM

Post #8 of 13 (1936 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

On Fri, Sep 4, 2009 at 12:33 AM, Shai Erera<serera [at] gmail> wrote:
> 2) Contribute my payload-based sorting package. Currently it only reads from
> disk during searches, and I'd like to enhance it to use in-memory cache as
> well. It's a moderate-size package, so this one will need to wait until (1)
> is done, and I get enough time to adapt it to 2.9 and work on the issue.

I've resisted using payloads for this purpose in Solr because it felt
like an interim hack until CSF is implemented. It feels like payloads
are properly used when one actually cares what the term or position
is. Thoughts? Do we think CSF will make it in 3.1?

-Yonik
http://www.lucidimagination.com

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

serera at gmail

Sep 6, 2009, 1:42 AM

Post #9 of 13 (1923 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

>
> I've resisted using payloads for this purpose in Solr because it felt
> like an interim hack until CSF is implemented.
>

I don't see it as a hack, but as a proper use of a great feature in Lucene.
CSF and this are essentially the same. Adding document-level metadata, or
adding a term which puts stuff in the payload feels the same to me. We'll
definitely need to perf. test the two and compare. The package I wrote
"hides" this payload stuff from the app developer. If after CSF is
introduced is makes sense to move to use it, it should be very simple to
change the sort-by-payload package to use it, w/o affecting apps too much (I
think and hope).

The term just describes the "sort-by" type (e.g. date, title, priority etc.)
and there is only one position and nobody really cares about it and needs to
know that.

Shai

On Sat, Sep 5, 2009 at 6:45 PM, Yonik Seeley <yonik [at] lucidimagination>wrote:

> On Fri, Sep 4, 2009 at 12:33 AM, Shai Erera<serera [at] gmail> wrote:
> > 2) Contribute my payload-based sorting package. Currently it only reads
> from
> > disk during searches, and I'd like to enhance it to use in-memory cache
> as
> > well. It's a moderate-size package, so this one will need to wait until
> (1)
> > is done, and I get enough time to adapt it to 2.9 and work on the issue.
>
> I've resisted using payloads for this purpose in Solr because it felt
> like an interim hack until CSF is implemented. It feels like payloads
> are properly used when one actually cares what the term or position
> is. Thoughts? Do we think CSF will make it in 3.1?
>
> -Yonik
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

hossman_lucene at fucit

Sep 8, 2009, 3:29 PM

Post #10 of 13 (1861 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

: Thanks Mike. I did not phrase well my understanding of Cache reload. I
: didn't mean literally as part of the reopen, but *because* of the reopen.
: Because FieldCache is tied to an IndexReader instance, after reopen it gets
: refreshed. If I keep my own Cache, I'll need to code that logic, and I
: prefer to use what's currently in Lucene. (Sloth? :) )

but there is no actually refresh anywhere in Lucene ... the first time
it's used on a reader, it's cached. when that reader gets garbage
collected, it's remved from the cache. the only way the reopen/segment
level sorting changed things is that in a multireader the indexreader refs
put in the cache are all segment readers ... so if you reopen a
multireader only the changed segments will need to be added to hte cache
(the others will still be there)

but extending FieldCache doesn't really help you get any reuse out of that
that you couldn't get with your own weakhashmap keyed on indexreaders --
the sorting code will always give your custom Sort the segment readers.

-Hoss

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

yonik at lucidimagination

Sep 8, 2009, 3:39 PM

Post #11 of 13 (1862 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

On Sun, Sep 6, 2009 at 4:42 AM, Shai Erera<serera [at] gmail> wrote:
>> I've resisted using payloads for this purpose in Solr because it felt
>> like an interim hack until CSF is implemented.
>
> I don't see it as a hack, but as a proper use of a great feature in Lucene.

It's proper use for an application perhaps, but not for core Lucene.
Applications are pretty much required to work with what's given in
Lucene... but Lucene developers can make better choices. Hence if at
all possible, work should be put into implementing CSF rather than
sorting by payloads.

> CSF and this are essentially the same.

In which case we wouldn't need CSF?

-Yonik
http://www.lucidimagination.com

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

serera at gmail

Sep 8, 2009, 8:46 PM

Post #12 of 13 (1865 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

I didn't say we won't need CSF, but that at least conceptually, CSF and my
sort-by-payload are the same. If however it turns out that CSF performs
better, then I'll definitely switch my sort-by-payload package to use it. I
thought that CSF is going to be implemented using payloads, but perhaps I'm
wrong.

Shai

On Wed, Sep 9, 2009 at 1:39 AM, Yonik Seeley <yonik [at] lucidimagination>wrote:

> On Sun, Sep 6, 2009 at 4:42 AM, Shai Erera<serera [at] gmail> wrote:
> >> I've resisted using payloads for this purpose in Solr because it felt
> >> like an interim hack until CSF is implemented.
> >
> > I don't see it as a hack, but as a proper use of a great feature in
> Lucene.
>
> It's proper use for an application perhaps, but not for core Lucene.
> Applications are pretty much required to work with what's given in
> Lucene... but Lucene developers can make better choices. Hence if at
> all possible, work should be put into implementing CSF rather than
> sorting by payloads.
>
> > CSF and this are essentially the same.
>
> In which case we wouldn't need CSF?
>
> -Yonik
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
> For additional commands, e-mail: java-user-help [at] lucene
>
>

jason.rutherglen at gmail

Sep 10, 2009, 10:03 AM

Post #13 of 13 (1788 views)
Permalink

Re: Extending Sort/FieldCache [In reply to]

I think CSF hasn't been implemented because it's only marginally
useful yet requires fairly significant rewrites of core code
(i.e. SegmentMerger) so no one's picked it up including myself.
An interim solution that fulfills the same function (quickly
loading field cache values) using what works reliably today
(i.e. payloads) is a good simple forward moving step.

Shai, feel free to open an issue and post your code. I'd will
check it out and help where possible.

On Tue, Sep 8, 2009 at 8:46 PM, Shai Erera <serera [at] gmail> wrote:
> I didn't say we won't need CSF, but that at least conceptually, CSF and my
> sort-by-payload are the same. If however it turns out that CSF performs
> better, then I'll definitely switch my sort-by-payload package to use it. I
> thought that CSF is going to be implemented using payloads, but perhaps I'm
> wrong.
>
> Shai
>
> On Wed, Sep 9, 2009 at 1:39 AM, Yonik Seeley <yonik [at] lucidimagination>wrote:
>
>> On Sun, Sep 6, 2009 at 4:42 AM, Shai Erera<serera [at] gmail> wrote:
>> >> I've resisted using payloads for this purpose in Solr because it felt
>> >> like an interim hack until CSF is implemented.
>> >
>> > I don't see it as a hack, but as a proper use of a great feature in
>> Lucene.
>>
>> It's proper use for an application perhaps, but not for core Lucene.
>> Applications are pretty much required to work with what's given in
>> Lucene... but Lucene developers can make better choices. �Hence if at
>> all possible, work should be put into implementing CSF rather than
>> sorting by payloads.
>>
>> > CSF and this are essentially the same.
>>
>> In which case we wouldn't need CSF?
>>
>> -Yonik
>> http://www.lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
>> For additional commands, e-mail: java-user-help [at] lucene
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe [at] lucene
For additional commands, e-mail: java-user-help [at] lucene

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads