[
https://issues.apache.org/jira/browse/LUCENE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724280#comment-13724280
]
Simon Willnauer commented on LUCENE-5152:
-----------------------------------------
bq. So its really just a BytesRef bug right?
well in theory that is true. Yet, if you have an arc in your hand you can
basically change it by passing it to a subsequent call to readNextTargetArc or
whatever that would override the values completely. BytesRef is tricky but not
the root cause of this issue. I do think that if you call:
{noformat}
public Arc<T> findTargetArc(int labelToMatch, Arc<T> follow, Arc<T> arc,
BytesReader in) throws IOException
{noformat}
it should always fill the arc that is provided so everything you do with it is
up to you. Aside of this I agree BytesRef is tricky and we should fix if
possible.
> Lucene FST is not immutale
> --------------------------
>
> Key: LUCENE-5152
> URL: https://issues.apache.org/jira/browse/LUCENE-5152
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/FSTs
> Affects Versions: 4.4
> Reporter: Simon Willnauer
> Priority: Blocker
> Fix For: 5.0, 4.5
>
> Attachments: LUCENE-5152.patch
>
>
> a spinnoff from LUCENE-5120 where the analyzing suggester modified a returned
> output from and FST (BytesRef) which caused sideffects in later execution.
> I added an assertion into the FST that checks if a cached root arc is
> modified and in-fact this happens for instance in our MemoryPostingsFormat
> and I bet we find more places. We need to think about how to make this less
> trappy since it can cause bugs that are super hard to find.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
