[
https://issues.apache.org/jira/browse/LUCENE-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1672:
----------------------------------
Attachment: LUCENE-1672.patch
Here is a first patch, deprecating all usages of File/String to specify a
directory. I am not sure, if I hit all, if somebody knows another one, tell it.
This patch also replaces FSDirectory.getDirectory() by FSDirectory.open() for
all non-deprecated methods. The deprecated IndexReader/IndexWriter and so on
methods still use FSDir.getDirectory because they sometimes depend on
refCounting (which is wrong). This is a bug related to LUCENE-1453.
I will post a later patch that fixes this by wrapping all IndexReaders
instantiated by File/String with a FilterIndexReader that manages the closing
of the underlying directory. All closeDirectory/closeDir pass-throughs
everywhere can then be removed.
This also fixes a small bug in IndexModifier to close the directory on close()
when dir was given as File/String.
I also removed File/String in the segment file finder (non-public API).
> 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
>
> Attachments: LUCENE-1672.patch
>
>
> 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
