I agree. One should provide Lucene with a unique path in the filesystem, one that is not intended to be used for any other purpose. All access to that path should be through Lucene's API. The fact that Lucene decides to create a directory there rather than a single file is an implementation detail.

This is an interesting case to consider. If Lucene created a single file at the provided path which stored the entire index, would one then be entitled to complain that one cannot make subdirectories of this file for other purposes? Clearly not. Someday we may in fact wish to implement Lucene that way.

Doug

Otis Gospodnetic wrote:
I am against making the suggested Lucene modification.
Lucene index structure may change in the future.  It is possible that
one day Lucene developers will need to use a hierarchy of directories
to implement some feature.

Therefore, Lucene users should be discouraged from creating
sub-directories under the Lucene index directory, and Lucene should
'reserve the right' to change the index structure in the future.

Otis



--- Esmond Pitt <[EMAIL PROTECTED]> wrote:

Erik

I'm not clear whether this is a 'yes' or a 'no'. For application
reasons I
would like to use a directory structure for indexes that mirrors the
collection structure of the site, so that there is a master index for
the
whole site and subindexes in subdirectories for each virtual site
(and so on
recursively while I am building subsubindexes for later
consolidation).

I can't see any reason why Lucene should adopt a policy of preventing
me
from doing this & of forcing me into something more complicated.
Especially
when in reality this policy is merely a bug  & very easily fixable.

EJP
----- Original Message ----- From: "Erik Hatcher" <[EMAIL PROTECTED]>
To: "Lucene Users List" <[EMAIL PROTECTED]>
Sent: Monday, December 08, 2003 10:47 AM
Subject: Re: FSDIrectory.create doesn't tolerate subdirectories




On Sunday, December 7, 2003, at 06:17 PM, Esmond Pitt wrote:

When creating an index, FSDirectory assumes that the directory

has no


subdirectories. If a non-empty subdirectory is present,
FSDirectory.create
fails to delete it and throws an IOException. As the subdirectory

is


not a
Lucene index file (although in my case it is a Lucene sub-index),

the


method
actually has no business attempting to delete it at all. Can this
behaviour
please be changed so that it doesn't attempt to delete

subdirectories


in an
index location at all?

This seems like an almost reasonable request, and easy enough to implement in FSDirectory.create. Lucene has no business deleting

other


files in that directory that it doesn't use either, although that

would


be a bit more difficult to implement I think.

But really, it seems that users of Lucene should view the index
directory as a black box and think of it as a single entity that

Lucene


manages by itself. Why do you need to put things into that

directory?


If you want to create multiple indexes, then I'd recommend you

create a


parent directory to hold them in which the outside world to your
application should view as a single entity that should not be

touched


either.

This is why the terminology in Lucene is FS*Directory* - let Lucene

own


it I say.

Erik




---------------------------------------------------------------------


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:

[EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to