lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Updated: (LUCENE-1672) Deprecate all String/File ctors/opens in IndexReader/IndexWriter/IndexSearcher
Date Tue, 02 Jun 2009 13:20:07 GMT


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 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:
>             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
> 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 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
> 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:
For additional commands, e-mail:

View raw message