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 <jason.rutherg...@gmail.com <mailto:jason.rutherg...@gmail.com>> 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
    <markrmil...@gmail.com <mailto:markrmil...@gmail.com>> 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
                <gsing...@apache.org <mailto:gsing...@apache.org>> 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:
                    java-dev-unsubscr...@lucene.apache.org
                    <mailto:java-dev-unsubscr...@lucene.apache.org>
                    For additional commands, e-mail:
                    java-dev-h...@lucene.apache.org
                    <mailto:java-dev-h...@lucene.apache.org>



                
---------------------------------------------------------------------
                To unsubscribe, e-mail:
                java-dev-unsubscr...@lucene.apache.org
                <mailto:java-dev-unsubscr...@lucene.apache.org>
                For additional commands, e-mail:
                java-dev-h...@lucene.apache.org
                <mailto:java-dev-h...@lucene.apache.org>



            
---------------------------------------------------------------------
            To unsubscribe, e-mail:
            java-dev-unsubscr...@lucene.apache.org
            <mailto:java-dev-unsubscr...@lucene.apache.org>
            For additional commands, e-mail:
            java-dev-h...@lucene.apache.org
            <mailto:java-dev-h...@lucene.apache.org>



-- - Mark

        http://www.lucidimagination.com





        ---------------------------------------------------------------------
        To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
        <mailto:java-dev-unsubscr...@lucene.apache.org>
        For additional commands, e-mail:
        java-dev-h...@lucene.apache.org
        <mailto:java-dev-h...@lucene.apache.org>





--
- Mark

http://www.lucidimagination.com




---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to