lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-2665) Rework FieldCache to be more flexible/general
Date Sun, 26 Sep 2010 10:48:32 GMT


Michael McCandless commented on LUCENE-2665:

bq. Apologies for 'CTR' rather then 'RTC' -- we can always revert if I jumped the gun!

Better to ask forgiveness than permission :)

In fact I'm +1 on switching Lucene's trunk to CTR model instead, now
that we have 3.x as the stable branch.  We have enough "policemen"
around here that I think this'd work well.

The changes look great Ryan -- nice work!  Some smallish feedback:

  * I see some windows eol's snuck in... can you change the
    svn:eol-style of all the new sources to "native"?

  * Some classes are missing copyright header (at least EntryKey,

  * Shouldn't we only incr .numDocs if the bit wasn't already set?
    (To be robust if docs have more than one value).  Ie we can use
    OpenBits.getAndSet.  Maybe then add and assert that numDoc <=
    maxDoc in the end...

  * Then, we can pass null for the delDocs to the enums, and then we
    don't need a 2nd pass to detect matchAllDocs (just test if
    .numDocs == maxDoc())?

I think we should hold off on backport to 3.x until we stabilize

It looks like you've also fixed LUCENE-2527 with this?  Ie the
fasterButMoreRAM=true|false now cache to the same key?  It's just that
perhaps we should "upgrade" the entry, if it was first created w/
false and then the current call passes true?

> Rework FieldCache to be more flexible/general
> ---------------------------------------------
>                 Key: LUCENE-2665
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Ryan McKinley
>         Attachments: LUCENE-2665-FieldCacheOverhaul.patch, LUCENE-2665-FieldCacheOverhaul.patch
> The existing FieldCache implementation is very rigid and does not allow much flexibility.
 In trying to implement simple features, it points to much larger structural problems.
> This patch aims to take a fresh approach to how we work with the FieldCache.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message