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]
