lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] Commented: (LUCENE-2282) Expose IndexFileNames as public, and make use of its methods in the code
Date Wed, 24 Feb 2010 04:37:29 GMT


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 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 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:
>             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
> 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:
For additional commands, e-mail:

View raw message