Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <1455799751.482271266986249261.JavaMail.jira@brutus.apache.org>
Date: Wed, 24 Feb 2010 04:37:29 +0000 (UTC)
From: "Shai Erera (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-2282) Expose IndexFileNames as public,
 and make use of its methods in the code
In-Reply-To: <2015928755.471731266958408367.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837624#action_12837624 ] 

Shai Erera commented on LUCENE-2282:
------------------------------------

bq. The thing is, I really don't understand what kind of thing you want to do.

Consider a variation of FileSwitchDirectory which someone wants to write. Extensions xyz, abc go do directory 1 and def got do directory 2. That someone will want to reference Lucene extensions in order to achieve that. FSD only takes care of extensions, but someone might need to work on prefixes of files as well.
You can say "that class itself should not care about Lucene's extensions, it should get the extensions/prefixes in a ctor" ...

Well ... let'stake FileSwitchDirectory (which is a core Lucene class) and say I want to instantiate it. I need to pass file extensions. How do I pass the .del file as an extension? Do I hard code it to ".del" (or just "del"?) or, or do I put that code in o.a.l.store just for that?  Or ... we make IndexFileNames publc and I can happily and safely reference it.
BTW, I'm writing this from a computer w/o the Lucene code -- I wonder how FSD is tested, is the test in o.a.l.index because it references IFN or in o.a.l.store because it tests FSD? If it's the latter, then I (usually) think it points at a problem in the design.

The @lucene.internal tag gives us exactly that freedom. Instead of me putting code in o.a.l.* (and feel like I'm dong something wrong, and make my code look wrong), I can put it in my package but know I'm risking the chance a certain constant or method impl will change in the future. I've already took that risk when I chose to put my code in o.a.l.* so I prefer to take that risk and not make my code look patchy.

I, personally, don't mind what Lucene's back-compat policy is. Whenever I upgrade my code to a new Lucene version, I re-compile anything. I am happy to get rid of deprecated API, I am happy to take advantage of new, more efficient API, and I wouldn't care if a @lucene.internal class changed, as long as it's documented in the "Changes in back-compat" section in CHANGES, as a FYI - not because it's a change in the policy, so I can read about it quickly (that's the first section I usually check).

That class is just a reference to Lucene's core files. If you want to write that 'Sweep' thing, you might benefit from knowing what is a core Lucene file and delegate the sweep task to a core Lucene instance, while sweeping the rest of the files by another instance (which created them?). If Lucene core will create files w/ other names/extensions, then I believe this class (IFN) should be changed entirely, but I don't think making it public blocks any of these changes, as long as it's tagged by @lucene.internal.

> Expose IndexFileNames as public, and make use of its methods in the code
> ------------------------------------------------------------------------
>
>                 Key: LUCENE-2282
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2282
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Shai Erera
>             Fix For: 3.1
>
>         Attachments: LUCENE-2282.patch, LUCENE-2282.patch
>
>
> IndexFileNames is useful for applications that extend Lucene, an in particular those who extend Directory or IndexWriter. It provides useful constants and methods to query whether a certain file is a core Lucene file or not. In addition, IndexFileNames should be used by Lucene's code to generate segment file names, or query whether a certain file matches a certain extension.
> I'll post the patch shortly.

-- 
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org