lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: Releasing 3.0.3
Date Thu, 14 Jun 2012 18:20:41 GMT
I can't guarantee that the code is 100% in compliance with java 3.0.3.  All
changes that could be ported have been ported in core and most contrib
projects.  There are a few things that should at least be discussed
regarding the compatibility in core:

Occur (BooleanClause) in java is converted to an enum, from static readonly
methods on a class.  The reason that was never ported was because we can't
override ToString() on an enum, even with extension methods and/or type
converters.  Currently, "MUST" evaluates to "+", SHOULD to "", and
"MUST_NOT" to "-".  I'd double check this, but I think that the ToString()
on occur is only used when creating string representations of a query.  So,
in theory, we could replace the usages in that location, and make the
conversion to enum.  This isn't a high-priority, especially since the
fields are static readonly, this likely doesn't affect performance much or
at all.

FuzzyQuery uses java.util.PriorityQueue<T> which doesn't exists in .NET.  I
think we wind up using a SortedList, which was just a temporary measure
that I wanted to make sure was fixed before release.  I've tried to
subclass from Util.PriorityQueue<T>, but it breaks a few tests.  The
current setup with SortedList works fine, but it's slower O(n) instead of
O(log n) I think for some actions, and it doesn't support duplicate
keys...which is bad.

SegmentInfos inherits from a thread-safe collection in java (Vector).  We
could have used SynchronizedCollection<T> and inherit from that, but I
chose not to.  I'm don't actually believe that lucene relies on the fact
that Vector is ThreadSafe; instead, handling synchronization on its own.
 However, it's worth checking into, even though there are no tests that
fail.  Perhaps try to write one?  IDK, there's a lot of multi-threaded
tests, and I've yet to see a failure that's related to this.  All
intermittent tests that currently fail, do so for other reasons.  Also, in
this class, there are a few places where it should be returning a read-only
HashSet, instead of returning a mutable one.

===================
Open issues:

I wanted to talk about the issues that are assigned, but just haven't had
time.  I think we really need to triage what is actually important and
focus on that.  I think I'll briefly just comment on a few of these and I
hope to find out what you guys think of the open issues as well.

I think can be moved to 3.5:
=========================
LUCENENET- 439 - Correctly Rethrow exceptions in C#
LUCENENET- 436 - Refactor Deprecated Code inside of tests
LUCENENET- 435 - Fix the test suite for Lucene.Net Core (java lucene has
refactored a lot of their test suite.  I think this should be backlogged)
LUCENENET- 467 - .NETify the public API where appropriate
-- Some of this has already been done, but it's not critical to a release.
LUCENENET- 456 -  Create a Build Target that outputs compiled artifacts in
apache release format

These are of medium importance
=========================
LUCENENET- 446 - Make Lucene.Net CLS Compliant
-- The major issues with this have been more-or-less solved.  The basic
public API is almost completely CLS-compliant, except for usages of sbyte
in FieldCacheRangeFilter and VerifyingLockFactory.  Almost all classes can
be used in other languages.  There are 58 CLS naming issues, but most of
them deal with protected members.  If consumers were to use the library as
is without customization, it's not blocking.  However, it's not ideal to
leave these issues in the release.
LUCENENET- 337 - TokenAttribute for Selectively Including Tokens in Length
Norm
-- This is just a patch.  I'm actually not sure what it does, so I haven't
committed it to trunk because of that.

High priority: These should be fixed or looked over before releasing
=========================
LUCENENET- 484 - Some possibly major tests intermittently fail
-- Obviously, we should try and have a test suite that consistently passes.
 There are only two that fail now, I think.
LUCENENET- 493 - Make lucene.net culture insensitive (like the java version)
LUCENENET- 490 - QueryParser is culture-sensitive
-- These two above are fairly important.  I don't know to what extent java
lucene is culture insensitive, though, and until I do some tests, I don't
want to jump in and start changing things.  There are culture sensitive
tests in the test suite, but they don't run because of JUnit and NUnit
differences.
LUCENENET- 470 - Change Getxxx() and Setxxx() methods to .NET Properties
-- This is practically done.  I think there are only a few places where
this should be updated.  I only put this in high priority, because the API
changes between 2.9 and 3.x are the perfect time to do this.  Almost all
obvious ones have been changed already.  There are a few others like
[typename].Size() that could probably be changed as well, but those would
have to be manually found.

Other's opinions and insights are appreciated.


Thanks,
Christopher

On Thu, Jun 14, 2012 at 8:58 AM, Prescott Nasser <geobmx540@hotmail.com>wrote:

>
> I'm going to try and review some of them - looking at the 3.5 ticket atm.
> The code should be in compliance with 3.0.3. We might want to do some spot
> checking various parts of the code. I'm not sure about the tests. Also, we
> should probably run some code coverage tools to see how much coverage we
> have.
> ~P
> > Date: Thu, 14 Jun 2012 18:37:12 +0300
> > Subject: Re: Releasing 3.0.3
> > From: itamar@code972.com
> > To: lucene-net-dev@lucene.apache.org
> >
> > Ok, and is the code in 100% compliance with the 3.0.3 Java code?
> >
> > I'll be spending some time on fixing the index corruption issue, and it
> is
> > probably best for Chris to wrap up the work he has started
> >
> > Anyone else on board to close some tickets?
> >
> > On Thu, Jun 14, 2012 at 6:19 PM, Prescott Nasser <geobmx540@hotmail.com
> >wrote:
> >
> > >
> > > Agreed -
> > > JIRA for 3.0.3
> > >
> https://issues.apache.org/jira/browse/LUCENENET/fixforversion/12316215#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
> > > We should evaluate all of these - fix them, mark as won't fix, or move
> > > them to another release version. I think the biggest hold up currently
> is:
> > > https://issues.apache.org/jira/browse/LUCENENET-484. Chris has made a
> > > huge dent, but there are two test cases that are still listed as
> failing (I
> > > can't even duplicate those failures to know where to start)
> > > Also we should look at all the other jira tickets and make updates
> where
> > > appropriate
> > > ~P
> > > > Date: Thu, 14 Jun 2012 13:21:04 +0300
> > > > Subject: Releasing 3.0.3
> > > > From: itamar@code972.com
> > > > To: lucene-net-dev@lucene.apache.org
> > > >
> > > > Where do we stand with this?
> > > >
> > > > I want to push to a 3.0.3 release, what items are still pending?
> > > >
> > > > Itamar.
> > >
> > >
>
>

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