[
https://issues.apache.org/jira/browse/LUCENE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-2282.
Resolution: Fixed
Thanks Shai!
> Expose IndexFileNames as public, and make
willing to recompile and regenerate to take
advantage of experimental features is a big boon, as it allows us to test
drive features before declaring them stable. Designing optimal APIs without
usability testing is difficult to impossible.
> Expose IndexFileNames as p
back port to 3.0.2 - it's non-trivial enough
that there is some risk?
Please no backport to 3.0.2, its an API change. And we are not sure if there
will be ever a 3.0.2. BTW: Version 3.0.1 comes out latest on Friday, will
appear on the mirrors soon!
> Expose IndexFileNames as public, an
of FSD fragile (potentially).
Thanks for looking at this !
> Expose IndexFileNames as public, and make use of its methods in the code
>
>
> Key: LUCENE-2282
> URL: https://issues.apach
ow
takes a Codec as input, to make up for that... but IndexFileNames just
has a NOTE at the top stating the limitation.
> Expose IndexFileNames as public, and make use of its methods in the code
>
>
>
[
https://issues.apache.org/jira/browse/LUCENE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-2282:
--
Assignee: Michael McCandless
> Expose IndexFileNames as public, and make
coding
"fdt" and "fdx". It couldn't have done that because IFN was package-private,
which shows the problem with it.
> Expose IndexFileNames as public, and make use of its methods in the code
> -
(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
pub
nstantiate 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
uot;non-core-Lucene" files when
writing a compound file.
Maybe there's something I haven't thought of, though. Why do you want to
"reference Lucene's file extensions properly"? Once you've identified
identified whi
[
https://issues.apache.org/jira/browse/LUCENE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2282:
---
Attachment: LUCENE-2282.patch
Forgot to tag IFN as @lucene.internal
> Expose IndexFileNames
om making it public.
The class already exists, and declares the right constants and methods. All I
want is to expose it as public. This information is not *hidden*, it's out
there. We're just making it easier for apps to reference it.
Like Mike mentioned on the java-dev thread
http://
ason and I cannot unlock it), but I see no
reasons for them to fail.
If this can go out in 3.0.2 instead of waiting for 3.1, then all the better.
> Expose IndexFileNames as public, and make use of its methods in the code
>
only core index files conflicts with the idea
of pluggable index formats. Presumably plugins would use their own file
extensions. Would these belong to the index, according to a detector based
off of IndexFileNames? Presumably not, which would either limit the
usefulness of such a utility, or outr
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
ok great !
I'll create an issue and work out a patch.
Shai
On Tue, Feb 23, 2010 at 1:52 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> On Tue, Feb 23, 2010 at 6:46 AM, Shai Erera wrote:
> > I don't think performance is the issue here, but rather correctness.
> Someone
> > cannot
On Tue, Feb 23, 2010 at 6:46 AM, Shai Erera wrote:
> I don't think performance is the issue here, but rather correctness. Someone
> cannot just ask filename.endsWith(DELETION_EXT) as files like "file1del"
> would match as well. So whenever you make such check, you need to add ".".
> Again, not per
I don't think performance is the issue here, but rather correctness. Someone
cannot just ask filename.endsWith(DELETION_EXT) as files like "file1del"
would match as well. So whenever you make such check, you need to add ".".
Again, not performance, but correctness.
If we make it public, then we ca
Well, there are two issues:
* We don't always call IFN.segmentFileName -- often we simply
concatenate strings directly throughout the sources.
* Should the extensions include '.' or not?
I'd really like to fix the first issue. If we do that, then there's
only 1 place that performs string co
But segmentFileName performs the concatenation internally:
static String segmentFileName(String segmentName, String ext) {
return segmentName + "." + ext;
}
So that would not avoid anything right?
And still, if someone needs to know whether a certain file is a core Lucene
file or his own a
This class makes me somewhat nervous, with the changes coming in flex,
because the extensions are no longer static but rather a function of
the particular codec you're using in the index. I've changed some of
the constants accordingly (on flex).
Still, I think it's OK to make it public (flex has
Hi,
I've noticed that IFN is package private, including its constants and
methods. Any reason why not make it public? I need to create my own
Directory, and would like to query whether a file is 'my file' or Lucene's
file. Getting access to the extensions can help. Currently I have to put my
code
Bernhard Messer wrote:
I finished the changes and commited the changes. There are two new
classes in package org.apache.lucene.index.
org.apache.lucene.index.IndexFileNames contains common lucene related
filenames and extensions, the scope of the class itself and it's members
are package. org.
Doug Cutting wrote:
Bernhard Messer wrote:
sorry for the confusion. On the first look, i thought the new class
IndexFileNames, containing the necessary constant values, fits
perfect into org.apache.lucene.index. After a more detailed look, i
get the feeling that it would be much better to
Bernhard Messer wrote:
sorry for the confusion. On the first look, i thought the new class
IndexFileNames, containing the necessary constant values, fits perfect
into org.apache.lucene.index. After a more detailed look, i get the
feeling that it would be much better to place the new class into
LuceneFileFilter, Constants.INDEX_* and
IndexReader.FILENAME_EXTENSIONS, should all be moved to a common home
in the index package, like org.apache.lucene.index.IndexFileNames.
Thoughts?
sorry for the confusion. On the first look, i thought the new class
IndexFileNames, containing the neces
Doug Cutting wrote:
[EMAIL PROTECTED] wrote:
---
lucene/java/trunk/src/java/org/apache/lucene/store/FSDirectory.java
(original)
+++
lucene/java/trunk/src/java/org/apache/lucene/store/FSDirectory.java
Mon Jun 6 10:52:12 2005
@@ -52,8 +52,8 @@
if (name.endsWith("."+IndexReader.FILE
[EMAIL PROTECTED] wrote:
--- lucene/java/trunk/src/java/org/apache/lucene/store/FSDirectory.java
(original)
+++ lucene/java/trunk/src/java/org/apache/lucene/store/FSDirectory.java Mon Jun
6 10:52:12 2005
@@ -52,8 +52,8 @@
if (name.endsWith("."+IndexReader.FILENAME_EXTENSIONS[i]))
28 matches
Mail list logo
