So for this scenario I guess I would have like to know the reader is
read-only. But if I understand you correctly, you say that writing my app
such that one method get a reader for doing some job on non-deleted
documents, while another get the same reader and might delete stuff is a bad
design anyw
On Thu, Jun 4, 2009 at 10:19 AM, Mark Miller wrote:
> If you use hasDeletions() with a non read-only
> Reader, then someone could delete out from under you, right?
Right... but calling isDeleted() doesn't fix that (because of race
conditions). You could call isDeleted(5) which would return false
Yonik Seeley wrote:
On Thu, Jun 4, 2009 at 9:37 AM, Mark Miller wrote:
I was thinking you have a read-only snapshot to check on the deletes though.
Another thread
can't do a delete with that Reader, and if they are doing it on another
Reader, it wouldn't
affect the snapshot the read-only Rea
On Thu, Jun 4, 2009 at 9:37 AM, Mark Miller wrote:
> I was thinking you have a read-only snapshot to check on the deletes though.
> Another thread
> can't do a delete with that Reader, and if they are doing it on another
> Reader, it wouldn't
> affect the snapshot the read-only Reader had opened?
Yonik Seeley wrote:
On Tue, Jun 2, 2009 at 4:54 AM, 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
so
On Tue, Jun 2, 2009 at 4:54 AM, 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
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
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
need
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
But it doesn't help the library. It can't assume there are no deletes just
because the reader is read only. And if you know you don't do deletes you
can skip calling isdeleted readonly or not. The only way this works cleanly
is if you could ask if the "index" is readonly, not the Reader. Knowing a
On Jun 1, 2009, at 8:48 AM, Mark Miller wrote:
Right. The app will know if the index is readonly.
Yes, but a library that was passed the reader may not.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For ad
On Jun 1, 2009, at 5:40 AM, Yonik Seeley wrote:
On May 30, 2009, at 13:27, Mark Miller 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.
But it's just a flag passed in
If you know it's read only and that th
Right. The app will know if the index is readonly. isReadonly would
only tell you the reader was readonly, not the index. A readonly
reader can be opened on an index with deletes. That why it's tricky.
It's not useful for what you might think you would use it for. At
least pure API wise.
> On May 30, 2009, at 13:27, Mark Miller 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.
>
> But it's just a flag passed in
>
> If you know it's read only and that there are no deletes, can't you avoid
> isDe
On May 30, 2009, at 13:27, Mark Miller 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.
But it's just a flag passed in
If you know it's read only and that there are no deletes, can't you
avoid isDeleted
+1
On May 29, 2009 11:27 PM, "Jason Rutherglen"
wrote:
Yeah!
On Fri, May 29, 2009 at 2:21 PM, Grant Ingersoll
wrote: > > Does it make sen...
On Sat, May 30, 2009 at 1:27 PM, Mark Miller wrote:
> Is there a valid use case?
That was my question too... I really can't think of one.
Maybe we should leave it out until there is actually a need for it.
-Yonik
http://www.lucidimagination.com
--
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 sy
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
wrote:
Does it make sense to add isReadOnly() to IndexReader such that one
can
easily introspect whether a Reader is read only?
-Grant
Makes sense!
Mike
On Fri, May 29, 2009 at 5:21 PM, Grant Ingersoll wrote:
> Does it make sense to add isReadOnly() to IndexReader such that one can
> easily introspect whether a Reader is read only?
>
> -Grant
>
> -
> To unsubsc
, 2009 11:21 PM
> To: java-dev@lucene.apache.org
> Subject: ReadOnly IndexReaders
>
> Does it make sense to add isReadOnly() to IndexReader such that one
> can easily introspect whether a Reader is read only?
>
> -Grant
>
> --
Yeah!
On Fri, May 29, 2009 at 2:21 PM, Grant Ingersoll 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:
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail:
23 matches
Mail list logo
