Document IDs will be re-utilized, after, say, optimization. One consequence of this is that optimization will change the IDs of *existing* documents.
You're right, that numdocs may well be shorter than maxdocs. That's what I get for reading quickly... Best Erick On 5/24/07, Carlos Pita <[EMAIL PROTECTED]> wrote:
> > > No. It will always be at least as large as the total documents. But that > will also count deleted documents. Do you mean that deleted document ids won't be reutilized, so the index maxDoc will grow more and more with time? Isn't there any way to compress the range? It seems strange to me, considering that an example in the book suggests to use the document id as an array index for an array of maxDoc elements. Cheers, Carlos Why wouldn't numdocs serve? > > Best > Erick > > > The motivation of this question is that I want to associate some info to > > each document in the index, and in order to access this additional data > in > > O(1) I would like to do this through an array indexing. But the array > size > > shouldn't be a lot greater than the total number of documents. I see > that > > something similar is done in the example of section 6.1 of Lucene in > > Action, > > but for sorting purposes, which is not my case. > > > > Related to this: how can update my array of extra data when documents > are > > added/removed to/from the index? Is there any feedback mechanism by > means > > of > > callbacks or event handlers? > > > > Thank you in advance. > > Regards, > > Carlos > > >
