lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (LUCENE-2282) Expose IndexFileNames as public, and make use of its methods in the code
Date Wed, 24 Feb 2010 04:39:27 GMT

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

Shai Erera edited comment on LUCENE-2282 at 2/24/10 4:37 AM:
-------------------------------------------------------------

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's take 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 former, 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.

      was (Author: shaie):
    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


Mime
View raw message