[
https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715089#action_12715089
]
Uwe Schindler commented on LUCENE-1672:
---------------------------------------
But the File argument has the same problem with passing all these
closeDirectory arguments around. If we wrap this using this FilterIndexReader,
ok, but as discussed yesterday, I would prefer to simply only allow Directory
as input parameter and leave specifying the dir impl to the user. Automatically
use FSDir.open() is also not the best choose, because then user ask again of
java-user (how to specify another impl and so on).
For the user it is just a little bit more code and the additional close() call
(which can normally left out for standard directories...)
> Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
> ------------------------------------------------------------------------------
>
> Key: LUCENE-1672
> URL: https://issues.apache.org/jira/browse/LUCENE-1672
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Fix For: 2.9
>
>
> During investigation of LUCENE-1658, I found out, that even LUCENE-1453 is
> not completely fixed.
> As 1658 deprecates all FSDirectory.getDirectory() static factories, we should
> not use them anymore. As the user is now free to choose the correct directory
> implementation using direct instantiation or using FSDir.open() he should no
> longer use all ctors/methods in IndexWriter/IndexReader/IndexSearcher & Co.
> that simply take path names as String or File and always instantiate the
> Directory himself.
> LUCENE-1453 currently works for the cached directory implementations from
> FSDir.getDirectory, but not with uncached, non refcounting FSDirs. Sometime
> reopen() closes the directory (as far as I see, when a SegmentReader changes
> to a MultiSegmentReader and/or deletes apply). This is hard to track. In
> Lucene 3.0 we then can remove the whole bunch of closeDirectory
> parameters/fields in these classes and simply do not care anymore about
> closing directories.
> To remove this closeDirectory parameter now (before 3.0) and also fix 1453
> correctly, an additional idea would be to change these factories that take
> the File/String to return the IndexReader wrapped by a FilteredIndexReader,
> that keeps track on closing the underlying directory after close and reopen.
> This is simplier than passing this boolean between different
> DirectoryIndexReader instances. The small performance impact by wrapping with
> FilterIndexReader should not be so bad, because the method is deprecated and
> we can state, that it is better to user the factory method with Directory
> parameter.
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
