lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From NightOwl888 <>
Subject [GitHub] lucenenet issue #191: [WIP] Migrating Lucene.Net to .NET Core
Date Thu, 10 Nov 2016 11:11:15 GMT
Github user NightOwl888 commented on the issue:
    > >    There are 2 different PriorityQueue types in Lucene.Net
    > Is there a reason for this? Can we stay with one?
    Yes, there is a reason for that – that is the way it is done in Lucene. As for sticking
with one I am not sure. The one the Lucene developers came up with seems much more specialized
than the one in the JDK, which is what our Support.PriorityQueue is a close match for.
    I noticed that there were modifications to the Util.PriorityQueue that were not in Lucene
(namely adding a default constructor and functionality to make it growable). There were also
major differences in the unit tests (I ported the original tests over, but left the extra
ones in place). I was hoping this was the cause of the null reference exception in one of
the tests in Misc, which I know can be fixed by simply making defensive coding against null,
but I was hoping to uncover and fix the root cause. Unfortunately, the Util.PriorityQueue
does not seem to be it. But it seems Connie has already resolved it on this branch.
    I also noticed that [Core.Search.TopTermsRewrite is referencing the wrong PriorityQueue](
I have it corrected here on a local branch, but haven’t yet run tests on it to see what
the total impact is (that particular class doesn’t have any unit tests). I suspect there
are other places where the wrong PriorityQueue is being used, which could affect the stability
of those pieces.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message