Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 13529 invoked from network); 13 Mar 2010 14:11:35 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 13 Mar 2010 14:11:35 -0000 Received: (qmail 59697 invoked by uid 500); 13 Mar 2010 14:10:55 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 59659 invoked by uid 500); 13 Mar 2010 14:10:55 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 59652 invoked by uid 99); 13 Mar 2010 14:10:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 13 Mar 2010 14:10:55 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of serera@gmail.com designates 209.85.219.217 as permitted sender) Received: from [209.85.219.217] (HELO mail-ew0-f217.google.com) (209.85.219.217) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 13 Mar 2010 14:10:52 +0000 Received: by ewy9 with SMTP id 9so207436ewy.11 for ; Sat, 13 Mar 2010 06:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=U5nIVEejEWL0I1N2uabKBWArho3E3sYUMLcjw+lZG94=; b=bdFacOzSq2DGJnxF+ox1jrNoe4jU38X95vE7f4byQjrMq3s/KJMmeZ/BpgxMDoOv3t RsIM0bLRUKmv2c9RWwDSVd7J8XHdseyLVCT7rR4rnl5UUK/w7vY/1jV2yaMd6zCVwiLO Oeko2jlHZjuVwzPdeEe8wz7DRaIZAQ9ZmLwMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=MAm8yOO8TFnQD8uANMa24jjHqG1Bclqdg3VK3J4+v4el2h22gCdmuqZn1d5fIb38Pb g2WdxOw98n9GQum3hI2nVe074svpu7Rl9rfWAGt1hINqvtsiN+9BKSPYcZGgrY9ZOTkR qL383seGysrfBHL2hO1kkwZzUb3FgsmLyrdtA= MIME-Version: 1.0 Received: by 10.213.1.150 with SMTP id 22mr1126868ebf.63.1268489431382; Sat, 13 Mar 2010 06:10:31 -0800 (PST) In-Reply-To: <9ac0c6aa1003130549p2036c0d2oda417f7d71173ddc@mail.gmail.com> References: <126142c1003121525v24499625u1589bbef4c0792e7@mail.gmail.com> <00ab01cac292$fe607af0$fb2170d0$@de> <126142c1003130321p42bd2fb2mf973c96569e5b434@mail.gmail.com> <786fde51003130446g6ca29f7cob5b1bbe229e4d637@mail.gmail.com> <9ac0c6aa1003130549p2036c0d2oda417f7d71173ddc@mail.gmail.com> Date: Sat, 13 Mar 2010 16:10:31 +0200 Message-ID: <786fde51003130610t766d7241q5cb8cf43f52a2d6d@mail.gmail.com> Subject: Re: Different behavior of Directory.fieldLength() From: Shai Erera To: java-dev@lucene.apache.org Content-Type: multipart/alternative; boundary=000e0cdff6faf57c670481af358c --000e0cdff6faf57c670481af358c Content-Type: text/plain; charset=ISO-8859-1 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 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 name 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 > > 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 > > --000e0cdff6faf57c670481af358c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 propos= ed 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 exten= sions
> 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 queryi= ng a file
> that does not exist. FSDirectory got away with it by using File API wh= ich
> just happens to return 0 for a non-existing file. RAMDirectory chose t= o
> alert the caller. My feeling is that these two were written by two dif= ferent
> persons, or separate times, each understanding the method differently.=
>
> I think we should make the semantics clear, and declare a better contr= act,
> 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 pr= obing
> 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&= gt; 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 y= ou 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 I= W code
> queries fileExists before. However if someone relies on FSDir to retur= n 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:
>
> /**
> =A0* @deprecated the method will become abstract when #fileLength(name= ) has
> been removed.
> =A0*/
> public long getFileLength(String name) throws IOException {
> =A0 long len =3D fileLength(name);
> =A0 if (len =3D=3D 0 && !fileExists(name)) {
> =A0=A0=A0 throw new FileNotFoundException(name);
> =A0 }
> =A0 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 st= ring 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.
>> =A0OK but what the about the exception?
>> =A0If 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 sho= uld
>> be modified to return 0.
>> =A0Best regards, Marcelo.
>>
>> --
>> Marcelo F. Ochoa
>> ht= tp://marceloochoa.blogspot.com/
>> http://mochoa.sites.exa.unicen.edu.ar/
>> ______________
>> Want to integrate Lucene and Oracle?
>>
>> http://marceloochoa.blogspo= t.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


--000e0cdff6faf57c670481af358c--