[jira] Updated: (LUCENE-569) NearSpans skipTo bug
[ http://issues.apache.org/jira/browse/LUCENE-569?page=all ] paul.elschot updated LUCENE-569: Attachment: NearSpans20060903.patch NearSpans20060903.patch combines the changes for the bug fix on the following files against revision 439747 (today): src/java/org/apache/lucene/search/spans/NearSpansOrdered.java, added src/java/org/apache/lucene/search/spans/NearSpansUnordered.java, added src/java/org/apache/lucene/search/spans/SpanNearQuery.java, changed src/test/org/apache/lucene/search/spans/TestNearSpans.java, added src/java/org/apache/lucene/search/spans/NearSpans.java, deleted. This obsoletes the patch to SpanNearQuery.java. (It leaves out one line of commented code that is in the separate patch for SpanNearQuery.java .) The added NearSpansUnordered is a simple specialisation of the deleted NearSpans for the unordered case. Regards, Paul Elschot NearSpans skipTo bug Key: LUCENE-569 URL: http://issues.apache.org/jira/browse/LUCENE-569 Project: Lucene - Java Issue Type: Bug Components: Search Reporter: Hoss Man Attachments: common-build.assertions.patch, NearSpans20060903.patch, NearSpansOrdered.java, NearSpansUnordered.java, SpanNearQuery20060622.patch, SpanScorer.explain.testcase.patch, TestNearSpans.java NearSpans appears to have a bug in skipTo that causes it to skip over some matching documents completely. I discovered this bug while investigating problems with SpanWeight.explain, but as far as I can tell the Bug is not specific to Explanations ... it seems like it could potentially result in incorrect matching in some situations where a SpanNearQuery is nested in another query such thatskipTo will be used ... I tried to create a high level test case to exploit the bug when searching, but i could not. TestCase exploiting the class using NearSpan and SpanScorer will follow... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-584) Decouple Filter from BitSet
[
http://issues.apache.org/jira/browse/LUCENE-584?page=comments#action_12432378 ]
Eks Dev commented on LUCENE-584:
Hi Paul,
for me, this patch did not cause any incompatibility issues. All our tests
passed without noticing any difference to the previous trunk version. No
performance changes as well ( we use HitCollector only, so Yoniks comment does
not apply here).
Tests are application level, and make index hot (6hrs searches with test batch
of requests with known responses), 50Mio not artificial docs, real requests...
Early this week we will try to implement our first Matchers and see how they
behave
Decouple Filter from BitSet
---
Key: LUCENE-584
URL: http://issues.apache.org/jira/browse/LUCENE-584
Project: Lucene - Java
Issue Type: Improvement
Components: Search
Affects Versions: 2.0.1
Reporter: Peter Schäfer
Priority: Minor
Attachments: BitsMatcher.java, Filter-20060628.patch,
HitCollector-20060628.patch, IndexSearcher-20060628.patch,
MatchCollector.java, Matcher.java, Matcher20060830b.patch,
Scorer-20060628.patch, Searchable-20060628.patch, Searcher-20060628.patch,
SortedVIntList.java, TestSortedVIntList.java
{code}
package org.apache.lucene.search;
public abstract class Filter implements java.io.Serializable
{
public abstract AbstractBitSet bits(IndexReader reader) throws IOException;
}
public interface AbstractBitSet
{
public boolean get(int index);
}
{code}
It would be useful if the method =Filter.bits()= returned an abstract
interface, instead of =java.util.BitSet=.
Use case: there is a very large index, and, depending on the user's
privileges, only a small portion of the index is actually visible.
Sparsely populated =java.util.BitSet=s are not efficient and waste lots of
memory. It would be desirable to have an alternative BitSet implementation
with smaller memory footprint.
Though it _is_ possibly to derive classes from =java.util.BitSet=, it was
obviously not designed for that purpose.
That's why I propose to use an interface instead. The default implementation
could still delegate to =java.util.BitSet=.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-658) upload major releases to ibiblio
[ http://issues.apache.org/jira/browse/LUCENE-658?page=comments#action_12432389 ] Jukka Zitting commented on LUCENE-658: -- This seems to be a duplicate of LUCENE-551. The releases are available at: http://www.ibiblio.org/maven2/org/apache/lucene/lucene-core/ upload major releases to ibiblio Key: LUCENE-658 URL: http://issues.apache.org/jira/browse/LUCENE-658 Project: Lucene - Java Issue Type: Task Components: Other Affects Versions: 1.9, 2.0.0 Reporter: Ryan Sonnek i'm a current user of maven and the latest 1.9 and 2.0 releases are not available on ibiblio. http://www.ibiblio.org/maven2/lucene/lucene/ Could someone upload the latest versions so that use maven-heads can access the new features? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-619) Lucene 1.9.1 and 2.0.0 Maven 2 packages are incorrectly deployed
[ http://issues.apache.org/jira/browse/LUCENE-619?page=comments#action_12432425 ] Otis Gospodnetic commented on LUCENE-619: - Actually, the Jar here looks invalid: http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/lucene/lucene-core/1.9.1/ Lucene 1.9.1 and 2.0.0 Maven 2 packages are incorrectly deployed Key: LUCENE-619 URL: http://issues.apache.org/jira/browse/LUCENE-619 Project: Lucene - Java Issue Type: Bug Affects Versions: 1.9, 2.0.0 Environment: http://www.ibiblio.org/maven2/org/apache/lucene/lucene-core/ Reporter: Jordan Christensen The lucene JARs at the URL listed in the Environment field only contain the maven 2 POMs, and not the actual compiled classes. The correct JARs need to be uploaded so that Lucene 1.9.1. and 2.0 can work in Maven 2. This was listed as fixed in http://issues.apache.org/jira/browse/LUCENE-551, but was not properly done. The JARs in the Apache Maven repo are incorrect as well. (http://www.apache.org/dist/maven-repository/org/apache/lucene/lucene-core/) This issue was raised and confirmed on the mailing list as well: http://www.gossamer-threads.com/lists/lucene/java-user/37169 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
