Otis,
First let me say, I don't want to rehash the arguments for or
against Java 1.5. We can all go back and read the last two major
threads on the issue. I don't think there is anything new to say.
However, I think statements like:
"no strong arguments" (I think the arguments were reasonable)
"only a few people argued for it" (Only a few argued against it)
"very little interest" (Very few votes are on any Jira issue, so
what does that say)
"adversaries" (I am not an adversary, I am a very interested party
with a personal interest in the outcome)
are inflammatory.
I am willing to do the back port if it is possible and if it does
not do violence to the implementation.
There are a number of patches sitting in Jira and it is not clear to
me which are even close to being applied. I am not interested in
doing work on patches that are old or might sit around for a while
until they are applied (and therefore become out of sync).
If the patches are identified as being worthy of being applied and
are also identified as being Java 1.5, I will port it and it's test
if it make sense.
It has already been granted that contrib allow Java 1.5. So I
presume that the build has been updated to allow for 1.5 in contrib
and not in core. If this is not the case I think that the first
committer (or submitter) of Java 1.5 code to contrib has the
responsibility to change the build system (or at least ensure that it
is done.)
As to the build system, I am not the right person to see that it
works. I am using Eclipse to do the builds. I maintain 2 workspaces,
one with core only and that is Java 1.4.2 and the other is core and
contrib and that is Java 1.5. I have done this so I can help "back
port" to Java 1.4.
However, I think you have identified that the core people need to
make a decision and the rest of us need to go with it. So, I suggest
that Doug convene such a meeting of the minds and communicate the
decision to the rest of us.
DM
On Jul 7, 2006, at 1:17 PM, Otis Gospodnetic wrote:
Hi Chuck,
I think bulk update would be good (although I'm not sure how it
would be different from batching deletes and adds, but I'm sure
there is a difference, or else you wouldn't have done it).
Java 1.5 - no conclusion, but personally I felt:
- no strong arguments for 1.4, only a few people argued for it
- very little interest from 1.4 adversaries in helping with
backporting to 1.4 or updating the build system to do the retro
thing with 1.5 code
So I think you should contribute your code. This will give us a
real example of having something possibly valuable, and written
with 1.5 features, so we can finalize 1.4 vs. 1.5 discussion,
probably with a vote on lucene-dev.
Otis
----- Original Message ----
From: Chuck Williams <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Thursday, July 6, 2006 5:07:41 PM
Subject: Re: [jira] Commented: (LUCENE-565) Supporting
deleteDocuments in IndexWriter (Code and Performance Results Provided)
robert engels wrote on 07/06/2006 12:24 PM:
I guess we just chose a much simpler way to do this...
Even with you code changes, to see the modification made using the
IndexWriter, it must be closed, and a new IndexReader opened.
So a far simpler way is to get the collection of updates first, then
using opened indexreader,
for each doc in collection
delete document using "key"
endfor
open indexwriter
for each doc in collection
add document
endfor
open indexreader
I don't see how your way is any faster. You must always flush to disk
and open the indexreader to see the changes.
....
Bulk updates however require yet another approach. Sorry to change
topics here, but I'm wondering if there was a final decision on the
question of java 1.5 in the core. If I submitted a bulk update
capability that required java 1.5, would it be eligible for
inclusion in
the core or not?
Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
