[
https://issues.apache.org/jira/browse/LUCENE-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902115#action_12902115
]
Hoss Man commented on LUCENE-2598:
----------------------------------
Of the top of my head...
What if we add some marker interfaces with no methods that the various
directories would implement, along the lines of "InMemoryBasedDirectory",
"NTFSFriendlyDirectory", etc.... Then change the "newDirectory(Random)" method
to "newDirectory(Random,Class...)"
Tests would specify a list of valid Directory "Classes" (either concrete or
interfaces) or nothing if they expect to work with any impl.
newDirectory would use reflection to expand the class/interface list from the
params to all known concrete types, and then likewise for the "tests.directory"
system property, and then intersect those lists of concrete directory
implementations, and pick randomly from it -- if the intersection is an empty
set (ie: the test said it's only valid for "FSDiskDirectory" but the user
specified -Dtests.directory=RAMDirectory) then newDirectory returns null and
signals that the test should skip (or fail). (most tests would just keep
calling newDirectory(random) and the default run prop becomes
-Dtests.directory=Directory)
There are simplifications that can be made -- eliminating the marker interfaces
and just having the tests pick concrete classes for example -- but ultimately a
decision still has to be made about what to do if "tests.directory" conflicts
with the impl the actual test says it can/can't work with.
(personally; i think marker interfaces would be useful outside of the tests, as
a documentation hint to users about what a given Directory subclass is capable
of - and having the test take advantage of them would help verify that they are
accurate, assuming we get the tests running on various platforms/filesystems)
> allow tests to use different Directory impls
> --------------------------------------------
>
> Key: LUCENE-2598
> URL: https://issues.apache.org/jira/browse/LUCENE-2598
> Project: Lucene - Java
> Issue Type: Test
> Components: Build
> Affects Versions: 3.1, 4.0
> Reporter: Robert Muir
> Assignee: Robert Muir
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2598.patch, LUCENE-2598.patch, LUCENE-2598.patch,
> LUCENE-2598.patch, LUCENE-2598.patch, LUCENE-2598.patch, LUCENE-2598.patch
>
>
> Now that all tests use MockRAMDirectory instead of RAMDirectory, they are all
> picky like windows and force our tests to
> close readers etc before closing the directory.
> I think we should do the following:
> # change new MockRAMDIrectory() in tests to .newDirectory(random)
> # LuceneTestCase[J4] tracks if all dirs are closed at tearDown and also
> cleans up temp dirs like solr.
> # factor out the Mockish stuff from MockRAMDirectory into MockDirectoryWrapper
> # allow a -Dtests.directoryImpl or simpler to specify the default Directory
> to use for tests: default being "random"
> i think theres a chance we might find some bugs that havent yet surfaced
> because they are easier to trigger with FSDir
> Furthermore, this would be beneficial to Directory-implementors as they could
> run the entire testsuite against their Directory impl, just like
> codec-implementors can do now.
--
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]
