lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-743) IndexReader.reopen()
Date Thu, 11 Oct 2007 18:43:52 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534123
] 

Hoss Man commented on LUCENE-743:
---------------------------------


in deciding "to clone or not clone" for the purposes of implementing reopen, it may make sense
to step back and ask a two broader questions...

1) what was the motivation for approaching reopen using clones in the first place
2) what does it inherently mean to clone an indexreader.

the answer to the first question, as i understand it, relates to the issue of indexreaders
not being "read only" object ... operations can be taken which modify the readers state, and
those operations can be flushed to disk when the reader is closed.  so readerB = readerA.reopen(closeOld=false)
and then readerA.delete(...) is called, there is ambiguity as to what should happen in readerB.
 so the clone route seems pretty straight forward if and only if we have an unambiguous concept
of cloning a reader (because then the clone approach to reopen becomes unambiguous as well).
 alternately, since reopen is a new method, we can resolve the ambiguity anyway we want, as
long as it's documented ... in theory we should pick a solution that seems to serve the most
benefit ... perhaps that solution is to document reopen with "if reopen(closeOld=false) returns
a new reader it will share state with the current reader, attempting to do the following operations
on this new reader will result in undefined behavior"

the answer the the second is only important if we want to go the cloning route ... but it
is pretty important in a larger sense then just reopening ... f we start to say that any of
the IndexReader classes are Clonable we have to be very clear about what that means in *all*
cases where someone might clone it in addition to reopen ... in particular, i worry about
what it means to clone a reader which has already had "write" operations performed on it (something
the clone based version of reopen will never do because a write operation indicates the reader
must be current), but some client code might as soon as we add the Clonable interface to a
class.



> IndexReader.reopen()
> --------------------
>
>                 Key: LUCENE-743
>                 URL: https://issues.apache.org/jira/browse/LUCENE-743
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>            Reporter: Otis Gospodnetic
>            Assignee: Michael Busch
>            Priority: Minor
>             Fix For: 2.3
>
>         Attachments: IndexReaderUtils.java, lucene-743-take2.patch, lucene-743.patch,
lucene-743.patch, lucene-743.patch, MyMultiReader.java, MySegmentReader.java, varient-no-isCloneSupported.BROKEN.patch
>
>
> This is Robert Engels' implementation of IndexReader.reopen() functionality, as a set
of 3 new classes (this was easier for him to implement, but should probably be folded into
the core, if this looks good).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message