Lucene - Core
  1. Lucene - Core
  2. LUCENE-2076

Add org.apache.lucene.store.FSDirectory.getDirectory()

    Details

    • Type: Wish Wish
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0
    • Fix Version/s: 4.0-ALPHA
    • Component/s: core/store
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed.

      One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things.

      Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release.

      Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net.

      1. FSDirectory.patch
        0.3 kB
        George Aroush

        Activity

        Hide
        George Aroush added a comment -

        Patch attached.

        Show
        George Aroush added a comment - Patch attached.
        Hide
        Uwe Schindler added a comment -

        I see no reason to duplicate this method, especially as Directory is a "reserved" word in Lucene, being the superclass of FSDirectory.

        I do not undertand the whole issue, why not simply call getFile() ?

        Show
        Uwe Schindler added a comment - I see no reason to duplicate this method, especially as Directory is a "reserved" word in Lucene, being the superclass of FSDirectory. I do not undertand the whole issue, why not simply call getFile() ?
        Hide
        Mark Miller added a comment -

        Perhaps getDir or something then? Not a fan of getFile either - its going to return a directory, and while I know a File can be either, getDir or getDirectory are more descriptive as to what you are getting. I don't even think getDirectory is a problem myself - it returns a File, so its pretty clear its not a Lucene Directory - we have an issue there no matter - a file system directory came around quite a bit before a Lucene Directory

        Show
        Mark Miller added a comment - Perhaps getDir or something then? Not a fan of getFile either - its going to return a directory, and while I know a File can be either, getDir or getDirectory are more descriptive as to what you are getting. I don't even think getDirectory is a problem myself - it returns a File, so its pretty clear its not a Lucene Directory - we have an issue there no matter - a file system directory came around quite a bit before a Lucene Directory
        Hide
        George Aroush added a comment -

        Mark's response is right on. I'm also fine with adding getDir(), but prefer to see getDirectory().

        Uwe, the issue (and I just realized, I didn't clarify this in my original description of this issue) is with the way Java treats java.io.File objects, which can be a file or a directory. As I pointed in the description of this issue, for .NET, a file is managed using System.IO.FileInfo, and a directory is managed using System.IO.DirectoryInfo. Up to Lucene.Net 2.4.0, all ports were done such that we are using System.IO.FileInfo. This meant, internally, and even for public API's, we have to first make sure the object is a directory before using it.

        With 2.9.1, anywhere we were using System.IO.FileInfo, we are now depreciating them in favor of using System.IO.DirectoryInfo. The one area where we could not do this is for org.apache.lucene.store.FSDirectory.getFile() this is because the issue is with the return type – thus, we can't overload the method name.

        This is why, in Lucene.Net, we added Lucene.Net.Store.FSDirectory.GetDirectory() and flaged Lucene.Net.Store.FSDirectory.GetFile() as depreciated. To keep the APIs consistent between Java and Lucene.Net, I'm requesting that Java Lucene add org.apache.lucene.store.FSDirectory.getDirectory().

        Show
        George Aroush added a comment - Mark's response is right on. I'm also fine with adding getDir(), but prefer to see getDirectory(). Uwe, the issue (and I just realized, I didn't clarify this in my original description of this issue) is with the way Java treats java.io.File objects, which can be a file or a directory. As I pointed in the description of this issue, for .NET, a file is managed using System.IO.FileInfo, and a directory is managed using System.IO.DirectoryInfo. Up to Lucene.Net 2.4.0, all ports were done such that we are using System.IO.FileInfo. This meant, internally, and even for public API's, we have to first make sure the object is a directory before using it. With 2.9.1, anywhere we were using System.IO.FileInfo, we are now depreciating them in favor of using System.IO.DirectoryInfo. The one area where we could not do this is for org.apache.lucene.store.FSDirectory.getFile() this is because the issue is with the return type – thus, we can't overload the method name. This is why, in Lucene.Net, we added Lucene.Net.Store.FSDirectory.GetDirectory() and flaged Lucene.Net.Store.FSDirectory.GetFile() as depreciated. To keep the APIs consistent between Java and Lucene.Net, I'm requesting that Java Lucene add org.apache.lucene.store.FSDirectory.getDirectory().
        Hide
        Michael McCandless added a comment -

        Shouldn't we deprecate getFile in the process? Ie we rename getFile -> getDirectory?

        Show
        Michael McCandless added a comment - Shouldn't we deprecate getFile in the process? Ie we rename getFile -> getDirectory?
        Hide
        Mark Miller added a comment -

        Yeah, I'd say so.

        Show
        Mark Miller added a comment - Yeah, I'd say so.
        Hide
        George Aroush added a comment -

        Under Lucene.Net 2.9.1, we have depreciated GetFIle, and added GetDirectory. If Java Lucene does the same, can this be done for 3.0?

        Show
        George Aroush added a comment - Under Lucene.Net 2.9.1, we have depreciated GetFIle, and added GetDirectory. If Java Lucene does the same, can this be done for 3.0?
        Hide
        Michael McCandless added a comment -

        If Java Lucene does the same, can this be done for 3.0?

        The problem is, we're trying hard to avoid new deprecations in 3.0. 2.9 was our chance to do deprecations. Can we do this for 3.1 instead?

        Show
        Michael McCandless added a comment - If Java Lucene does the same, can this be done for 3.0? The problem is, we're trying hard to avoid new deprecations in 3.0. 2.9 was our chance to do deprecations. Can we do this for 3.1 instead?
        Hide
        Uwe Schindler added a comment -

        Because of that I moved this issue to 3.1. The RC phase of 3.0 started yesterday evening.

        Show
        Uwe Schindler added a comment - Because of that I moved this issue to 3.1. The RC phase of 3.0 started yesterday evening.
        Hide
        George Aroush added a comment -

        Sure, 3.1 will do. Thanks guys!

        Show
        George Aroush added a comment - Sure, 3.1 will do. Thanks guys!
        Hide
        Michael McCandless added a comment -

        Thanks George!

        Show
        Michael McCandless added a comment - Thanks George!

          People

          • Assignee:
            Michael McCandless
            Reporter:
            George Aroush
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development