lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Sale" <dougs...@gmail.com>
Subject Re: Some questions about recent patch delivery to the trunk
Date Sat, 20 Dec 2008 06:13:40 GMT
George,

I'll let Digy respond to the FSDirectory modifications, as IIRC they are
his.

However, the TestStressIndexing2 mods are mine.  There are fairly extensive
comments here:
https://issues.apache.org/jira/browse/LUCENENET-143  To make a long story
short, the Java test works in spite of itself.  I can comment more fully, if
necessary, but I'll have to review the changes to be more specific.

-Doug

On Fri, Dec 19, 2008 at 8:37 PM, George Aroush <george@aroush.net> wrote:

> Hi Digy, and Doug
>
> I have done a code review on the patches that were delivered to the trunk,
> and I have some questions:
>
> * DocumentsWriter.cs
> - What is ReadToEnd()?  I don't see it being used from anywhere, and it
> doesn't exists in the Java version of Lucene.  Lets remove it please.
>
> * FSDirectory.cs
> - The constructor FSIndexInput() and FSIndexOutput() have a loop which try
> to create a Descriptor / BinaryWriter object.  This loop has a try / catch
> and loops 10 times before it gives up.  There is no such logic in the Java
> version of Lucene; why was this added to Lucene.Net?  Why 10 times but not
> 5, 2, 100?  This bothers me since it may be hiding a real port issue.  If
> this loop is a must, due to the way .NET works, a comment is required to
> explain the divergence.
>
> * TestStressIndexing2.cs
> - In IndexSerial(), there is a comment that reads "nonono - can't do this
> ..." and then the line fields.Sort(fieldNameComparator) is commented out,
> why?  This is not the case for Java; in Java it's sorted by calling
> Collections.sort(fields, fieldNameComparator).
> - In VerifyEquals(), some new C# only code is added (for debugging?)  It's
> best to avoid such extra code to help reduce delta(s) when working on new
> port.
>
> I don't know which patch introduced the above, still I consider them
> divergence from the Java code and should be fixed.
>
> Regards,
>
> -- George
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message