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
