lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Directory.list() deprecation
Date Mon, 09 Nov 2009 13:44:27 GMT
On Sun, Nov 8, 2009 at 4:58 PM, Daniel Noll <> wrote:

>> Well... you can use oal.index.IndexFileNameFilter.getFilter() to
>> filter for only the Lucene index files, or, you could filter for the
>> additional files you know you've placed in the index directory?
> This is the workaround we're currently using, but it's pretty obvious
> why it's less than ideal:
>    FileNameFilter filter = IndexFileNameFilter.getFilter();
>    List<String> results = new ArrayList<String>();
>    for (String candidate : dir.listAll()) {
>        if (filter.accept(null, candidate)) {  // <--
>            results.add(candidate);
>        }
>    }
> The biggest issue here is that the FileNameFilter forces us to provide
> a File for the first parameter even though the index may not even be
> stored on disk.  We can pass null and hope that the filter won't have
> an issue with that, which works ... *for now*.

I don't expect IndexFileNameFilter will ever look at that (File
directory) argument.  Lucene itself does the same thing (passes null),
internally, whenever it uses IndexFileNameFilter.

>> The motivation for this change was that Directory is the wrong place
>> to have "smarts" about what is & isn't an index file: it's too
>> low-level (and, different Directory impls were inconsistent).
>> Especially with flexible indexing coming, where a codec can write
>> whatever files it wants, the Directory has no way know.
> This seems reasonable, but it would have been nice to have a list
> method which accepted a filter so that there would at least be a
> replacement for the old behaviour.  The way it is now, Lucene has
> deprecated a method people were using while providing no replacement
> except for "write it yourself", the same as what happened when Hits
> got canned.

Honestly I thought the effort to write the above code was trivial
enough that preserving this inside Lucene was not necessary.  But I
guess would have been good to include such a code fragment in the
javadocs for list().

Stepping back, since presumably your app knows what it's storing in
the directory, can't you filter for files you know you've created?
What's the larger use case here?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message