[
https://issues.apache.org/jira/browse/LUCENE-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968723#action_12968723
]
Robert Muir commented on LUCENE-2804:
-------------------------------------
bq. Of all the tests we have, only one calls this method and from what I can
tell, for no good reason. The method just copies the incoming Dir to another
one, an operation I think is useless for tests purposes.
Let me explain why this is: there are a number of tests that:
# build up a dir with IW
# in a loop, copy the dir into several other dir(s) and do scary tests
when i converted things to newDirectory, i only did the "easy tests". I think i
did one of these more scary ones. We should do the others.
I think it can make sense for a test to do this, if it wants to look for some
race condition or something and doesnt want to re-index into a new dir in each
loop.
However...
bq. I think that newDirectory(Directory) is weird. I'd think we'll have a
newDirectory(File) which will either return a FSDir on that File, or a RAMDir
where the files are copied into it.
I think newDirectory(File) is a good idea! But i still think we should keep the
other one. So newDirectory(File) could be done with:
{noformat}
SimpleFSDirectory fs = new SimpleFSDirectory(file);
Directory ret = newDirectory(fs);
fs.close();
return ret;
{noformat}
> check all tests that use FSDirectory.open
> -----------------------------------------
>
> Key: LUCENE-2804
> URL: https://issues.apache.org/jira/browse/LUCENE-2804
> Project: Lucene - Java
> Issue Type: Test
> Reporter: Robert Muir
>
> In LUCENE-2471 we were discussing the copyBytes issue, and Shai and I had a
> discussion about how we could prevent such bugs in the future.
> One thing that lead to the bug existing in our code for so long, was that it
> only happened on windows (e.g. never failed in hudson!)
> This was because the bug only happened if you were copying from
> SimpleFSDirectory, and the test used FSDirectory.open
> Today the situation is improving: most tests use newDirectory() which is
> random by default and never use FSDir.open,
> it always uses SimpleFS or NIOFS so that the same random seed will reproduce
> across both windows and unix.
> So I think we need to review all uses of FSDirectory.open in our tests, and
> minimize these.
> In general tests should use newDirectory().
> If the test comes with say a zip-file and wants to explicitly open stuff from
> disk, I think it should open the contents with say SimpleFSDir,
> and then call newDirectory(Directory) to copy into a new "random"
> implementation for actual testing. This method already exists:
> {noformat}
> /**
> * Returns a new Dictionary instance, with contents copied from the
> * provided directory. See {...@link #newDirectory()} for more
> * information.
> */
> public static MockDirectoryWrapper newDirectory(Directory d) throws
> IOException {
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
