lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Tagliavini Ponce <t-gu...@microsoft.com>
Subject RE: About two Store failing tests
Date Tue, 03 Feb 2015 02:01:12 GMT
Hi,

I found a difference between Java and C# implementations. Specifically, in the method GetCanonicalPath
(getCanonicalPath in Java) from the class FSDirectory, Lucene creates a File object but not
a file in the FS (the comment in the head of that method is wrong, because constructing a
File object does not create it in the FS), while the .Net version was creating it. Fixing
that difference, the two mysterious tests pass.

In my most recent PR I changed that. 

Guido

-----Original Message-----
From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On Behalf Of Itamar
Syn-Hershko
Sent: Tuesday, January 27, 2015 1:29 PM
To: dev@lucenenet.apache.org
Subject: Re: About two Store failing tests

If you mean:

// LUCENENET TODO mysterious failure - FSDirectory recreates the folder by design, not sure
why this passes for Java Lucene

That was me. I pinged someone from Java Lucene to get some reasoning but never heard back.
Will try again now. Another option is to debug line-by-line and side by side the .NET and
the Java code for the same test, and see maybe they are taking different code paths. I'm assuming
that'd be the case. Then try understanding why...

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko> Freelance Developer
& Consultant Lucene.NET committer and PMC member

On Tue, Jan 27, 2015 at 9:43 PM, Guido Tagliavini Ponce < t-gupon@microsoft.com> wrote:

> Hi devs,
>
> This email is about two of the Store's tests:
>
> *         core/Store/TestNRTCachingDirectory.cs - TestNoDir
>
> *         core/Store/TestFileSwitchDirectory.cs - TestNoDir
>
> Essentially, both create temporary directories, delete them, and use 
> its information to create more specific directories 
> (NRTCachingDirectory and FileSwitchDirectory). Just after constructing 
> the latter ones, they assert that those directories do not exist which 
> will be false because the constructors create the directories if they 
> do not exist (in the case of NRTCachingDirectory, the directory is 
> created before calling the constructor using the NewFSDirectory 
> method). Another person already pointed out this in a comment in the first one of the
tests.
>
> The easy fix for this would be adding deletion instructions after the 
> second round of constructions. But by doing this we could be hiding 
> some other problem under the rug. Two possibilities that come to my mind:
>
> 1.       They forgot to delete the directories just before the assertions.
> This seems unlikely to be happening because it would be an obvious bug.
>
> 2.       The directories' implementations changed over the time but they
> forgot to change the tests: Maybe, initially, they didn't create the 
> directories if they didn't exist beforehand.
>
> Knowing the goal of the test could help deciding. If they wanted to 
> test if they could delete those type of directories, then option 1 
> could be the right one. If they wanted to test that they don't create 
> directories if they don't exist, the other option would fit better with it.
>
> Am I missing out some other possibility? What should we do with those 
> tests?
>
> Best regards,
>
> Guido
>
Mime
View raw message