lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LUCENE-6135) re-number fields randomly in tests
Date Wed, 24 Dec 2014 17:58:13 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Muir updated LUCENE-6135:
--------------------------------
    Attachment: LUCENE-6135.patch

Here's a patch. I inserted bugs into stored fields merging and the new test in BaseStoredFieldsTestCase
fails instantly.

We also randomly wrap readers in merge and in newSearcher for checks all around. This itself
won't find bugs in bulk merge because it uses FilterReader, but its good safety.

> re-number fields randomly in tests
> ----------------------------------
>
>                 Key: LUCENE-6135
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6135
>             Project: Lucene - Core
>          Issue Type: Test
>            Reporter: Robert Muir
>         Attachments: LUCENE-6135.patch
>
>
> Currently some code (such as stored fields bulk merge) depends upon consistent field
number ordering. 
> In the case field numbers do not align, then optimizations are disabled, because the
would cause crazy corruption where values are mixed up across different fields. 
> But this is hardly tested today. If i introduce an intentional bug into this logic, then
only one lone test fails: TestAddIndexes.testFieldNamesChanged, and only about 10% of the
time at best. In general tests pass.
> {code}
> --- lucene/core/src/java/org/apache/lucene/codecs/compressing/MatchingReaders.java	(revision
1647793)
> +++ lucene/core/src/java/org/apache/lucene/codecs/compressing/MatchingReaders.java	(working
copy)
> @@ -52,6 +52,10 @@
>      for (int i = 0; i < numReaders; i++) {
>        for (FieldInfo fi : mergeState.fieldInfos[i]) {
>          FieldInfo other = mergeState.mergeFieldInfos.fieldInfo(fi.number);
> +        // nocommit:
> +        if (true) {
> +          break;
> +        }
>          if (other == null || !other.name.equals(fi.name)) {
>            continue nextReader;
>          }
> {code}
> Don't get me wrong, its a great simple test, but it should not be the only one doing
this. And it would be great if it failed more often, i havent looked as to why it only fails
rarely if there is a bug in this stuff.
> But in general, we should simulate this more. My current idea is to shuffle up field
numbers in MockRandomMergePolicy. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message