Filed the bug, https://issues.apache.org/jira/browse/LUCENE-511 .
Also added the simple fix, it seems to work, and I think the rest of
the method is ok.
Shay
On 2 Mar 2006, at 19:19, Doug Cutting wrote:
Shay Banon wrote:
...
} else {
// is data larger then buffer?
if (le
Steven Tamm wrote:
We just discovered this problem as well. Here's a test case that fails
without the fix.
Can you please attach this patch file to:
http://issues.apache.org/jira/browse/LUCENE-511
Thanks,
Doug
-
To unsubsc
void testLargeWrites() throws IOException {
+IndexOutput os = dir.createOutput("testBufferStart.txt");
+
+byte[] largeBuf = new byte[2048];
+for (int i=0; imailto:[EMAIL PROTECTED]
Sent: Thursday, March 02, 2006 11:20 AM
To: java-dev@lucene.apache.org
Subject: Re
Shay Banon wrote:
...
} else {
// is data larger then buffer?
if (length > BUFFER_SIZE) {
// we flush the buffer
if (bufferPosition > 0)
flush();
// and write data at once
flushBuffer(b, length);
} else {
...
the bufferStart is not
Hi,
I have just updated to lucene 1.9, and hit a problem with the
mentioned optimization. I have applied it to the my
JdbcBufferedOutput (I only duplicate the code because the BUFFER_SIZE
is final), and I hit a problem. In the following code fragment (the
method is writeBytes):
...
Maxim Patramanskij wrote:
Doug,
what about including optimization of BuffereIndexOutput.writeBytes()
method:
[ http://issues.apache.org/jira/browse/LUCENE-435?page=all ]
made by Lukas Zapletal, into 1.9?
I just committed this to trunk. If no issues arise with it there then
perhaps we can
Chris Hostetter wrote:
I think moving forward the query parser and fileformat docs should be
moved into docfile directories within the java source, so they are
reved/tagged with the individual releases. That way when people have
questions about the file format of their index built with 1.9 they
--- Nadav Har'El <[EMAIL PROTECTED]> wrote:
> Dan Armbrust <[EMAIL PROTECTED]> wrote
> on 17/02/2006 08:50:53
> PM:
...
> So I'm not sure the solution is to change the
> semantics of the existing
> constructor, but I think Lucene definitely need a
> new constructor or
> convenience
> function that
Dan Armbrust <[EMAIL PROTECTED]> wrote on 17/02/2006 08:50:53
PM:
>...
> Short summary - The Constructor for IndexWriter currently will only
> create an index in a folder if you set the boolean create flag to true.
> But then, if you want to append to that index, you have to set the
> create flag
I'd like to see this improvement request implemented - but I'm not sure
if 1.9 or 2.0 would be a better place to do it:
http://issues.apache.org/jira/browse/LUCENE-301
Short summary - The Constructor for IndexWriter currently will only
create an index in a folder if you set the boolean create
Maxim - vote for it. Not guaranteed to get tihngs in, but votes helps us see
what people need/want/like.
Otis
- Original Message
From: Maxim Patramanskij <[EMAIL PROTECTED]>
To: Doug Cutting
Sent: Wednesday, February 15, 2006 7:25:52 AM
Subject: Re: 1.9 RC1
Doug,
what
This week is pretty booked for me, so, barring major objections, I will
make a 1.9 RC1 release next Monday, February 20th. If there are no
problems discovered, I'll aim to make a 1.9 final release a week later,
around the 27th.
Has anyone tested if 1.9 can build with a Free Software toolchain
DM Smith wrote:
Would that mean that 1.9 and 2.0 will be released at the same time?
No. 2.0 will be released after 1.9. The primary change will be that
all deprecated methods are removed, but there may be other changes, but
probably not many.
Doug
Erik Hatcher wrote:
On Feb 15, 2006, at 9:11 AM, DM Smith wrote:
Not to get to far ahead, but what is the schedule relation between
1.9 and 2.0?
What are the dependencies on releasing 2.0?
My understanding is that 2.0 will be 1.9 with all the deprecated API
removed. Maybe there are other fe
On Feb 15, 2006, at 9:11 AM, DM Smith wrote:
Not to get to far ahead, but what is the schedule relation between
1.9 and 2.0?
What are the dependencies on releasing 2.0?
My understanding is that 2.0 will be 1.9 with all the deprecated API
removed. Maybe there are other features planned?
Not to get to far ahead, but what is the schedule relation between 1.9
and 2.0?
What are the dependencies on releasing 2.0?
Doug Cutting wrote:
I'd like to push out a 1.9 release candidate in the next week or so.
Are there any patches folks are really hoping to sneak into 1.9? If
so, now's th
Doug,
what about including optimization of BuffereIndexOutput.writeBytes()
method:
[ http://issues.apache.org/jira/browse/LUCENE-435?page=all ]
made by Lukas Zapletal, into 1.9?
I'm wondering, because this can decrease index creation time, which I
discovered as critical when using Lucene toget
I've been away from constant e-mail for several days (nice while it
lasted, but rough to come back to!)...
I'm +1 for 1.9 RC1, just for the record. As for the copyright years
- those should reflect only the years those files were touched, at
least that is how it is carefully done with Ant
Chris Hostetter wrote:
I'm not sure what the ASF/Lucene policy is on keeping Copyright/License
statements in source files up to date, but should they all be updated to
say "Copyright 2006 The Apache Software Foundation" prior to a 1.9
release?
It shouldn't hurt!
This week is pretty booked for
: I'd like to push out a 1.9 release candidate in the next week or so.
I'm not sure what the ASF/Lucene policy is on keeping Copyright/License
statements in source files up to date, but should they all be updated to
say "Copyright 2006 The Apache Software Foundation" prior to a 1.9
release?
I've
: This is a great time to improve the javadoc. I see lots of blank boxes
: which could use a bit of descriptive text, for example:
That reminds me about a documentation/release issue that's been rolling
arround in the back of my mind that seems like it's only going to get
worse as future release
Doug Cutting wrote:
I'd like to push out a 1.9 release candidate in the next week or so. Are
there any patches folks are really hoping to sneak into 1.9? If so,
now's the time.
This is a great time to improve the javadoc. I see lots of blank boxes
which could use a bit of descriptive text,
22 matches
Mail list logo
