The javadocs used to say "this method returns null when there are no
matching fields". I removed that. Maybe I should add back in "this
method returns an empty array when there are no matching fields"?
Mike
Nicolas Lalevée wrote:
Hi,
Even if this improvement make sense, I think you br
Hi,
Even if this improvement make sense, I think you broke some compatibility
there.
But as it was not specified in the javadoc, I don't know how "compatible" it
is.
So at least could the javadoc be more precise about what to expect as returned
values ?
thanks,
Nicolas
Le vendredi 14 mars 2
[
https://issues.apache.org/jira/browse/LUCENE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579367#action_12579367
]
Christian Kohlschütter commented on LUCENE-954:
---
I agree with Hoss. Please fi
Le lundi 17 mars 2008, Michael McCandless a écrit :
> The javadocs used to say "this method returns null when there are no
> matching fields". I removed that. Maybe I should add back in "this
> method returns an empty array when there are no matching fields"?
In fact there were some "This method
Nicolas Lalevée wrote:
Le lundi 17 mars 2008, Michael McCandless a écrit :
The javadocs used to say "this method returns null when there are no
matching fields". I removed that. Maybe I should add back in "this
method returns an empty array when there are no matching fields"?
In fact there
On Monday 17 March 2008 11:12:53 Michael McCandless wrote:
> The javadocs used to say "this method returns null when there are no
> matching fields". I removed that. Maybe I should add back in "this
> method returns an empty array when there are no matching fields"?
I generally prefer that the j
Developers Resources Documentation
--
Key: LUCENE-1237
URL: https://issues.apache.org/jira/browse/LUCENE-1237
Project: Lucene - Java
Issue Type: Bug
Reporter: Grant Ingersoll
Priority:
[
https://issues.apache.org/jira/browse/LUCENE-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-1202.
-
Resolution: Fixed
OK, I confirm that Clover reports are now being generated. Looks like
I was playing around with LUCENE-831 last night and think I may have run
into a bug?
Can anyone verify that this should work?
Open IndexWriter
AddDocs
Commit IndexWriter
Open Reader
SeeDocs
AddNewDocs
Commit IndexWriter
ReopenReader
SeeNewDocs
I have not been able to SeeNewDocs. The IndexReade
I was playing around with LUCENE-831 last night and think I may have run into
a bug?
Can anyone verify that this should work?
Open IndexWriter
AddDocs
Commit IndexWriter
Open Reader
SeeDocs
AddNewDocs
Commit IndexWriter
ReopenReader
SeeNewDocs
I have not been able to SeeNewDocs. The IndexReader
Hi Mark,
Both of those cases are expected to work.
This sounds alot like LUCENE-1228 which was just fixed a few days
ago. Can you verify you have that fix in your area?
Mike
markrmiller wrote:
I was playing around with LUCENE-831 last night and think I may
have run into
a bug?
Can a
Bingo. Thanks Mike. Forgot how fast things move around here...my
checkout was a few days old.
Michael McCandless wrote:
Hi Mark,
Both of those cases are expected to work.
This sounds alot like LUCENE-1228 which was just fixed a few days
ago. Can you verify you have that fix in your area?
Phew :)
Mike
Mark Miller wrote:
Bingo. Thanks Mike. Forgot how fast things move around here...my
checkout was a few days old.
Michael McCandless wrote:
Hi Mark,
Both of those cases are expected to work.
This sounds alot like LUCENE-1228 which was just fixed a few days
ago. Can you ve
you can also use the payload to store the docid. michael had a posting on
that a while back.
-John
On Sun, Mar 16, 2008 at 11:43 PM, Chris Hostetter <[EMAIL PROTECTED]>
wrote:
>
> : I'd like to have an up-to-date map from unique-ids to lucene internal
> : doc-nums.
>
> Which way do you want the m
[
https://issues.apache.org/jira/browse/LUCENE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-510:
--
Attachment: LUCENE-510.take2.patch
New rev of the patch. I think it's ready to commit.
Hi,
I'm working on LUCENE-1219, which I think is a good improvement to the
Field API for creating stored binary fields based on parts of a shared
byte[].
I'm not really happy with the current patch because our hands are tied
by the fact that we have Fieldable as an interface. I'd really like
to
additionaly, this very reason makes something like
Document.getBinaryValue(String name, byte[] myBuffer);, to put it mildly,
impractical. This could be handy way to reduce allocations when fetching as
stored fields can be big
- Original Message
From: Michael McCandless <[EMAIL PRO
[
https://issues.apache.org/jira/browse/LUCENE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579708#action_12579708
]
Hiroaki Kawai commented on LUCENE-510:
--
I'm wondering why the patch doesn't utilize ja
See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/408/changes
Changes:
[doronc] fix formatting in CHANGES.txt to prevent perl errors in creating
changes.html.
[mikemccand] LUCENE-1233: correct javadocs
--
[...truncated 5827 lines...]
[junit]
intermittent faiures of TestTimeLimitedCollector.testTimeoutMultiThreaded in
nightly tests
---
Key: LUCENE-1238
URL: https://issues.apache.org/jira/browse/LUCENE-1238
[
https://issues.apache.org/jira/browse/LUCENE-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen reassigned LUCENE-1238:
---
Assignee: Doron Cohen
> intermittent faiures of TestTimeLimitedCollector.testTimeoutMultiTh
21 matches
Mail list logo
