You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2017/01/05 23:35:58 UTC

[jira] [Updated] (SOLR-9934) SolrTestCase.clearIndex should ensure IndexWriter.deleteAll is called

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

Hoss Man updated SOLR-9934:
---------------------------
    Attachment: SOLR-9934.patch


Some background...

Once upon a time, if if you gave solr a DBQ of {{\*\:\*}}, it would optimize that internally into throwing away the current Index/IndexWriter and opening a brand new one from scratch.  Around the time of SOLR-3559 this had to be changed (git SHA 0f808c6bcdfcb11ce1398fe3c79c9b28c851aa1c) to account for the possibility that updates could arrive out of order, and all DBQs (even {{\*\:\*}}) needed their versions checked against doc versions in the index.

At the time of this change, special code was added to DUH2 so that some tests could still force the old behavior -- notably in cases where tests created synthetic versions and generally broke the tlog...

{noformat}
  // since we make up fake versions in these tests, we can get messed up by a DBQ with a real version
  // since Solr can think following updates were reordered.
{noformat}


Recently as part of the work ishan and I have been doing in SOLR-5944, we realized another issue with the current behavior is that even the test code is well behaved as var as versions/tlog go, and even though {{clearIndex}} is being called in {{\@Before}} methods, the low level field metdata in the IndexWriter (ex: what fields have docvalues) is surviving, causing inconsistent behavior between test methods (depending on the order of the test methods)

----

In my opinion, the behavior of {{SolrTestCaseJ4.clearIndex()}} should be to do the lowest possible level of "clear the index" (not just "do a \*:\* DBQ)  so that low level IndexWriter metadata doesn't survive, and people writting unit tests aren't suprised by stuff like this in future.

The attached patch refactors all the various copy/pasted versions of {{clearIndex()}} that take advantage of this low level delete up into {{SolrTestCaseJ4.clearIndex()}} and adds javadocs explaining how it differs from doing your own {{\*:\*}} DBQ.


> SolrTestCase.clearIndex should ensure IndexWriter.deleteAll is called
> ---------------------------------------------------------------------
>
>                 Key: SOLR-9934
>                 URL: https://issues.apache.org/jira/browse/SOLR-9934
>             Project: Solr
>          Issue Type: Test
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>         Attachments: SOLR-9934.patch
>
>
> Normal deleteByQuery commands are subject to version constraint checks due to the possibility of out of order updates, but DUH2 has special support (triggered by {{version=-Long.MAX_VALUE}} for use by tests to override these version constraints and do a low level {{IndexWriter.deleteAll()}} call.  A handful of tests override {{SolrTestCaseJ4.clearIndex()}} to take advantage of this (using copy/pasted impls), but given the intended purpose/usage of {{SolrTestCaseJ4.clearIndex()}}, it seems like the the base method in {{SolrTestCaseJ4}} should itself trigger this low level deletion, so tests get this behavior automatically.



--
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