[ https://issues.apache.org/jira/browse/LUCENE-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914990#action_12914990 ]
Michael McCandless commented on LUCENE-2527: -------------------------------------------- I believe LUCENE-2649 has fixed this, in that you will no longer get a double entry, and so whoever first populates this key "wins". I think this is the right policy (vs a 2nd requires upgrading to fasterButMoreRAM=true, in place). So I think all we should do here is add a test case that asserts that you don't get a double entry. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org