Good point Shai. A mix of hasDeletes and is isReadOnly does appear to be
useful then.
- Mark
Shai Erera wrote:
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] <mailto:[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] <mailto:[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] <mailto:[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]
<mailto:[email protected]>
For additional commands, e-mail:
[email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail:
[email protected]
<mailto:[email protected]>
For additional commands, e-mail:
[email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail:
[email protected]
<mailto:[email protected]>
For additional commands, e-mail:
[email protected]
<mailto:[email protected]>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail:
[email protected]
<mailto:[email protected]>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
