[
https://issues.apache.org/jira/browse/LUCENE-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915058#action_12915058
]
Ryan McKinley commented on LUCENE-2527:
---------------------------------------
Yes, LUCENE-2649 puts fasterButMoreRAM= true or false in the same entry.
Whatever is called first is what gets used (without warning)
One option is to 'upgrade' the cache value -- but I'm not sure which one is the
upgrade. Perhaps the last one that you ask for? If that is the case, would we
need another option that says "I would like it fasterButMoreRAM unless you
already have it cached different"
I think documenting that the setting needs to be used consistently is good. If
we have an error stream, then this would be an appropriate place to log an
error/warning.
> FieldCache.getTermsIndex should cache fasterButMoreRAM=true|false to the same
> cache key
> ---------------------------------------------------------------------------------------
>
> Key: LUCENE-2527
> URL: https://issues.apache.org/jira/browse/LUCENE-2527
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 4.0
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 4.0
>
>
> When we cutover FieldCache to use shared byte[] blocks, we added the boolean
> fasterButMoreRAM option, so you could tradeoff time/space.
> It defaults to true.
> The thinking is that an expert user, who wants to use false, could
> pre-populate FieldCache by loading the field with false, and then later when
> sorting on that field it'd use that same entry.
> But there's a bug -- when sorting, it then loads a 2nd entry with "true".
> This is because the Entry.custom in FieldCache participates in
> equals/hashCode.
--
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: [email protected]
For additional commands, e-mail: [email protected]