Hello Andy,
Thanks for your input. I understand what you are saying and trying to use
lucene as a relational db is a little too far, however,
in certain specialized areas, lucene works better than relational databases.
If you can setup the scheme, so that it is non-normalized, and if you dont
need
I get the id's to delete from a query in indexsearcher.
I think I am going trunk, hope it wont cause a lot of pain.
best.
-C.B.
On Sat, Aug 9, 2008 at 2:30 AM, Michael McCandless <
[EMAIL PROTECTED]> wrote:
>
> It's risky.
>
> How would you get the IDs to know which ones to delete? A separate
It's risky.
How would you get the IDs to know which ones to delete? A separate
reader running on the side?
The problem is, as IndexWriter merges segments, the IDs shift. Any
reader you have already open won't see this shift (until you reopen
it), so you could end up deleting the wrong
I rarely submit but I've been seeing this sort of thing more and more
on this board.
It seems that there is a need to treat Lucene as if it were a data
storage or database like repository, where in
fact it isn't.
In our case, for large indexes we run either a parallel process to
create the index
hello,
what would happen if I modified the class IndexWriter, and made the delete
by id method public?
I have two fields in my documents and I got to be able to delete by those
two fields, (by query in other words) and I do not wish to go trunk version.
I am getting quite desperate, and if not f
