lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Different behavior of Directory.fieldLength()
Date Sat, 13 Mar 2010 14:49:04 GMT
Thanks!

Mike

On Sat, Mar 13, 2010 at 9:10 AM, Shai Erera <serera@gmail.com> wrote:
> Ok, opened LUCENE-2316 to track this.
>
> Shai
>
> On Sat, Mar 13, 2010 at 3:49 PM, Michael McCandless
> <lucene@mikemccandless.com> wrote:
>>
>> I like the proposed new semantics (throw FNFE if the file does not
>> exist), and the migration path (new method, deprecate old).
>>
>> Mike
>>
>> On Sat, Mar 13, 2010 at 7:46 AM, Shai Erera <serera@gmail.com> wrote:
>> > I think it falls under the semantics of dir.fileLength() and not the
>> > semantics of the implementation right? Unfortunately, the semantics of
>> > Directory.fileLength() are not specified, which made it easy for
>> > extensions
>> > to invent their own.
>> >
>> > I myself am not sure what's better - return 0 as the length for a file
>> > that
>> > does not exist, or throw FNFE to alert the caller that he's querying a
>> > file
>> > that does not exist. FSDirectory got away with it by using File API
>> > which
>> > just happens to return 0 for a non-existing file. RAMDirectory chose to
>> > alert the caller. My feeling is that these two were written by two
>> > different
>> > persons, or separate times, each understanding the method differently.
>> >
>> > I think we should make the semantics clear, and declare a better
>> > contract,
>> > by documentation and possible also by method signature. If for example
>> > we
>> > decide that it should return 0 for non-existing files, then I think we
>> > can
>> > remove the IOException from the method sig? But maybe we want to allow
>> > IOException to be thrown by Directories that could actually fail on
>> > probing
>> > the file length.
>> >
>> > I would propose to declare the semantics of fileLength like this:
>> > * Returns the length of the file denoted by <code>name</code> if
the
>> > file
>> > exists. The return value may be anywhere between 0 and Long.MAX_VALUE.
>> > * Throws FileNotFoundException if the file does not exist. Note that you
>> > can
>> > call dir.fileExists(name) if you are not sure whether the file exists or
>> > not.
>> >
>> > That way it's clear. We can then change IW code to call fileExists if it
>> > expects to fail on either of the two.
>> >
>> > Question is - how do we do this w/o breaking Directory implementations
>> > out
>> > there? I think that we might be safe with it, if we make sure all of IW
>> > code
>> > queries fileExists before. However if someone relies on FSDir to return
>> > 0
>> > instead of throwing exception, that will break his app.
>> >
>> > Backwards is always tricky. This does not result in compilation error,
>> > but a
>> > runtime change. We might be able to get away with it if we think users
>> > run
>> > some tests before they deploy a new Lucene .jar ... but otherwise, we
>> > should
>> > create a new method, w/ clear semantics? Something like:
>> >
>> > /**
>> >  * @deprecated the method will become abstract when #fileLength(name)
>> > has
>> > been removed.
>> >  */
>> > public long getFileLength(String name) throws IOException {
>> >   long len = fileLength(name);
>> >   if (len == 0 && !fileExists(name)) {
>> >     throw new FileNotFoundException(name);
>> >   }
>> >   return len;
>> > }
>> >
>> > The first line just calls the current impl. If it throws exception for a
>> > non-existing file, we're ok. The second line verifies whether a 0 length
>> > is
>> > for an existing file or not and throws an exception appropriately.
>> >
>> > That is of course only if everybody else agree w/ these semantics.
>> >
>> > Shai
>> >
>> > On Sat, Mar 13, 2010 at 1:21 PM, Marcelo Ochoa <marcelo.ochoa@gmail.com>
>> > wrote:
>> >>
>> >> Uwe:
>> >> > That is not true, the API says:
>> >> > "Creates a new File *instance* from a parent pathname string and a
>> >> > child
>> >> > pathname string."
>> >> >
>> >> > Please note "instance", so it will never create the file on disk. New
>> >> > File() just creates a file instance but no file on disk. You can
>> >> > check this
>> >> > with a simple test.
>> >>  OK but what the about the exception?
>> >>  If the creation of the File instance do not throw an exception and
>> >> the method File.length() returns 0 if a file does not exists
>> >> RAMDirectory and other classes which also override this method should
>> >> be modified to return 0.
>> >>  Best regards, Marcelo.
>> >>
>> >> --
>> >> Marcelo F. Ochoa
>> >> http://marceloochoa.blogspot.com/
>> >> http://mochoa.sites.exa.unicen.edu.ar/
>> >> ______________
>> >> Want to integrate Lucene and Oracle?
>> >>
>> >>
>> >> http://marceloochoa.blogspot.com/2007/09/running-lucene-inside-your-oracle-jvm.html
>> >> Is Oracle 11g REST ready?
>> >> http://marceloochoa.blogspot.com/2008/02/is-oracle-11g-rest-ready.html
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: java-dev-help@lucene.apache.org
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message