[
https://issues.apache.org/jira/browse/LUCENE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646482#comment-16646482
]
Tim Owen commented on LUCENE-7394:
----------------------------------
Related to this (although I am happy to raise a separate Jira as a bug report)
is that mutating a MemoryIndex by calling addField you can end up with a
corrupt internal state (and ArrayIndexOutOfBoundsException) if you've done a
search on the index beforehand e.g. call addField, then search, then addField
again, then search. This appears to be because the sortedTerms internal state
gets built when the first search happens, and isn't invalidated/null'd when the
next addField happens. So the second search sees a state where sortedTerms and
terms are out of sync, and fails.
The documentation doesn't say this is a bad sequence of usage (or prevent it)
so making it immutable with a Builder would fix that situation. Alternatively,
calling search could implicitly call freeze, or addField could null out
sortedTerms.
> Make MemoryIndex immutable
> --------------------------
>
> Key: LUCENE-7394
> URL: https://issues.apache.org/jira/browse/LUCENE-7394
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Martijn van Groningen
> Priority: Major
>
> The MemoryIndex itself should just be a builder that constructs an
> IndexReader instance. The whole notion of freezing a memory index should be
> removed.
> While we change this we should also clean this class up. There are many
> methods to add a field, we should just have a single method that accepts a
> `IndexableField`.
> The `keywordTokenStream(...)` method is unused and untested and should be
> removed and it doesn't belong with the memory index.
> The `setSimilarity(...)`, `createSearcher(...)` and `search(...)` methods
> should be removed, because the MemoryIndex should just be responsible for
> creating an IndexReader instance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
