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 rel
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
On Sun, Sep 6, 2009 at 4:42 AM, Shai Erera 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, b
: 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'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 put
On Fri, Sep 4, 2009 at 12:33 AM, Shai Erera 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
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
As in "There's no virtue in re-inventing the wheel. No matter how
productive it feels" .
Best
Erick
On Fri, Sep 4, 2009 at 12:19 PM, Shai Erera wrote:
> Thanks Mi
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
On Fri, Sep 4, 2009 at 12:33 AM, Shai Erera 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 st
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 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
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
: 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
13 matches
Mail list logo
