lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-5152) Lucene FST is not immutable
Date Thu, 08 Aug 2013 15:29:48 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733598#comment-13733598
] 

Michael McCandless commented on LUCENE-5152:
--------------------------------------------

bq. Can you elaborate what you are afraid of?

In general I think it's bad if an assert changes too much how the code
would run without asserts.  E.g., maybe this O(N^2) assert alters how
threads are scheduled and changes how / whether an issue appears in
practice.

Similarly, if a user is having trouble, I'll recommend turning on
asserts to see if one trips, but if this causes a change in how the
code runs then this can change whether the issue reproduces.

I also just don't like O(N^2) code, even when it's under an assert :)

I think asserts should minimize their impact to the real code when
possible, and it certainly seems possible in this case.

Separately, we really should run our tests w/o asserts, too, since
this is how our users typically run (I know some tests fail if
assertions are off ... we'd have to fix them).  What if we accidentally
commit "real" code behind an assert?  Our tests wouldn't catch it ...

                
> Lucene FST is not immutable
> ---------------------------
>
>                 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, LUCENE-5152.patch, 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message