You could call reader.hasDeletions to decide whether you should call isdeleted()? But you cannot use that alone, since if a library receives an IndexReader, it cannot rely solely on hasDeletions, since at an upper level someone might decide to delete a document w/ that reader, and therefore it needs to couple hasDeletions with isReadOnly. I think?
On Tue, Jun 2, 2009 at 2:19 AM, Jason Rutherglen <[email protected] > wrote: > Currently there's ReadOnlyMultiSegmentReader and ReadOnlySegmentReader, > which calling instanceof on an IndexReader is a current hacked package > protected way of finding out if a reader is read only. I wrote code before > which checked by calling instanceof on both, which seemed a bit strange. > > > On Sat, May 30, 2009 at 10:27 AM, Mark Miller <[email protected]>wrote: > >> Is there a valid use case? It seems like it might be a tricky method, >> because its an IndexReader property and not the index. A user should >> probably technically treat read-only/non-read-only the same because it does >> not imply a different IndexReader didn't make changes/do deletes? >> >> It doesn't sync deletes, but should you use the API any differently? >> >> I don't see it hurting anything of course, but is there a real use case? >> >> >> Grant Ingersoll wrote: >> >>> OK, I'll do it. >>> >>> On May 30, 2009, at 8:29 AM, Michael McCandless wrote: >>> >>> Makes sense! >>>> >>>> Mike >>>> >>>> On Fri, May 29, 2009 at 5:21 PM, Grant Ingersoll <[email protected]> >>>> wrote: >>>> >>>>> Does it make sense to add isReadOnly() to IndexReader such that one can >>>>> easily introspect whether a Reader is read only? >>>>> >>>>> -Grant >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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] >>> >>> >> >> -- >> - Mark >> >> http://www.lucidimagination.com >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
