lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Serebrennikov <>
Subject Re: file handle changes
Date Tue, 23 Sep 2003 22:56:04 GMT
Doug Cutting wrote:

> Dmitry Serebrennikov wrote:
>> Doug, I've really considered keeping everything at the Directory 
>> level, as you suggested. This would have been preferred, I agree, but 
>> I really couldn't find a way to reconsile this approach with the 
>> other two goals I had: (a) keep specific file extension knowledge at 
>> the lucene.index.* level where it is now, and (b) avoid having to 
>> support writes to the compound file.
> Sorry I'm a little behind on my Lucene email.
> I just posted an alternate design before I saw this message.  But now 
> I see that your changes layer nicely on the existing Directory API, so 
> I don't really have a problem with them.  Although perhaps the 
> proposal in my previous message still has merit... What do you think? 

See my reply to that message. Generally, I think it would require too 
much change to the Directory API (and everyone's favorite directory 
implementations). Plus I like the way directory is structured now - nice 
and clean. And any way you slice it, adding any kind of call to say to a 
directory "please consider that you can now combine these files, even 
though you may not care since they are really database records for you, 
or something", just didn't seem very compelling :). The best I could 
come up with was something like setting some files are "read-only" and 
letting directory take it from there, but even then we still need to 
group related files...

Any way, I think it all worked out nicely. Even better than I thought it 
might - just one call on the IndexWriter does the job, plus IndexWriter 
is something that Lucene users have to deal with already.

> Does CompoundFileReader need to be public? 

No, it doesn't. I didn't think about that in the cleaup after the 
implementation. Feel free to make it package level.

> Doug
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message