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