lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2598) allow tests to use different Directory impls
Date Tue, 24 Aug 2010 22:32:19 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message