[
http://issues.apache.org/jira/browse/LUCENE-372?page=comments#action_12445343 ]
Andreas Neumann commented on LUCENE-372:
The reason for this is that the parse() method does not ensure that the entire
input string has been consumed. Que
[
http://issues.apache.org/jira/browse/LUCENE-372?page=comments#action_12445343 ]
Andreas Neumann commented on LUCENE-372:
The reason for this is that the parse() method does not ensure that the entire
input string has been consumed. Que
Disk full during addIndexes(Directory[]) can corrupt index
--
Key: LUCENE-702
URL: http://issues.apache.org/jira/browse/LUCENE-702
Project: Lucene - Java
Issue Type: Bug
Compo
[
http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12445305 ]
Michael McCandless commented on LUCENE-555:
---
Just copying this off the dev list -- there is indeed at least one place where
if a writer crashes it can le
Ning Li wrote:
It's only upon successfully writing the new segments that Lucene will
write a new "segments" file referring to the new segments. After
that, it removes the old segments. Since it makes these changes in
the correct order, it should be the case that disk full exception
never aff
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12445301 ]
Michael McCandless commented on LUCENE-665:
---
Doron, I finally managed to see an exception like yours above, but I had to
have the Windows Explorer open t
[ http://issues.apache.org/jira/browse/LUCENE-701?page=all ]
Michael McCandless updated LUCENE-701:
--
Attachment: index.prelockless.nocfs.zip
ZIP file that needs to be put in src/test/org/apache/lucene/index (used by
backwards compatibility test).
[ http://issues.apache.org/jira/browse/LUCENE-701?page=all ]
Michael McCandless updated LUCENE-701:
--
Attachment: index.prelockless.cfs.zip
ZIP file that needs to be put in src/test/org/apache/lucene/index (used by
backwards compatibility test).
>
[ http://issues.apache.org/jira/browse/LUCENE-701?page=all ]
Michael McCandless updated LUCENE-701:
--
Attachment: lockless-commits-patch.txt
> Lock-less commits
> -
>
> Key: LUCENE-701
> URL: http://iss
Lock-less commits
-
Key: LUCENE-701
URL: http://issues.apache.org/jira/browse/LUCENE-701
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Affects Versions: 2.1
Reporter: Michael McCan
[ http://issues.apache.org/jira/browse/LUCENE-697?page=all ]
Doron Cohen updated LUCENE-697:
---
Lucene Fields: [Patch Available] (was: [New])
> Scorer.skipTo affects sloppyPhrase scoring
> --
>
> Key:
[
http://issues.apache.org/jira/browse/LUCENE-569?page=comments#action_12445294 ]
Doron Cohen commented on LUCENE-569:
Chris Hostetter wrote:
> Really? ... the build.xml currently sets the javac -source and -target to
> 1.4 so if that were t
Damn, funky webmail, sorry about the earlier incomplete message.
Attempt #2:
Steven,
Regarding your payloads example and 2.1 vs. 3.0, there is a simpler approach,
and one that we have pretty much (unintentionally?) been using. Larger chunks
of work take longer, need more eyes to check them, t
Sev
- Original Message
From: Steven Parkes <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Friday, October 27, 2006 4:45:16 PM
Subject: RE: releases
not neccessarily ... if somethings in the trunk, you're saying
it should
be included in a release eventually ... but that
[ http://issues.apache.org/jira/browse/LUCENE-697?page=all ]
Doron Cohen updated LUCENE-697:
---
Attachment: sloppy_phrase_skipTo.patch
This was tricky, for me anyhow, but I think I found it.
The difference in scoring between using next() to using skipTo() (
[
http://issues.apache.org/jira/browse/LUCENE-569?page=comments#action_12445286 ]
Steven Parkes commented on LUCENE-569:
--
I don't think so. And I'm glad someone is checking. Got a patch, Doron?
> NearSpans skipTo bug
>
: It seems that having "assert()" in NearSpanOrdered.java now required
: Java 1.5 in order to compile Lucene. This would require 1.5 for running
: Lucene. Do we want to include this now?
Really? ... the build.xml currently sets the javac -source and -target to
1.4 so if that were true i would ex
[
http://issues.apache.org/jira/browse/LUCENE-569?page=comments#action_12445284 ]
Doron Cohen commented on LUCENE-569:
It seems that having "assert()" in NearSpanOrdered.java now required Java
1.5 in order to compile Lucene. This would re
I'd like to suggest a minor change in the QueryParser.jj. I thought
I'd describe it here and get some feedback before posting a patch.
The issue is that I can't get my hands on some clauses (typically
PhraseQuery instances) in my subclass of MultiFieldQueryParser, which
I'd like to do to implemen
[ http://issues.apache.org/jira/browse/LUCENE-569?page=all ]
Hoss Man resolved LUCENE-569.
-
Resolution: Fixed
Thanks again for figuring all of this out Paul.
> NearSpans skipTo bug
>
>
> Key: LUCENE-569
>
not neccessarily ... if somethings in the trunk, you're saying
it should
be included in a release eventually ... but that doesn't
neccessarily need
ot be the 2.1 release ,it might be the 3.0 release
I can see this in theory, but do our use patterns for svn support it? My
un
: Is there a way to invoke an ant test indicating the testcase _and_ the
: testmethod to be called?
not as far as i know ... in the JUnit model the entire class is "the test"
the individual test* methods are just various things you want to check in
that test (i've even seen people argue that a si
: That is on purpose, for now. The idea was to introduce a new functionnality
: without changing the way things worked before. But yes, it would be possible
: to make it so that, if wanted, the English operators could be "disabled".
Hmmm... i think i see what you mean, eliminating the english ope
: And an observation: shouldn't everything currently in Resolved have a
: FVs that includes 2.1? I can see optionally adding 2.0.1, too, but since
: it's already committed to trunk, it's obviously planned to be fixed in
: 2.1, right?
not neccessarily ... if somethings in the trunk, you're saying
[
http://issues.apache.org/jira/browse/LUCENE-569?page=comments#action_12445215 ]
Paul Elschot commented on LUCENE-569:
-
Hoss, thanks for the modifications. The tst* methods were indeed renamed from
test*.
Is there a way to invoke an ant te
It's only upon successfully writing the new segments that Lucene will write a new
"segments" file referring to the new segments. After that, it removes the old
segments. Since it makes these changes in the correct order, it should be the case that
disk full exception never affects the already
26 matches
Mail list logo
