Hani is suggesting embedding the time stamp in the file name, so that
the file does not need to be opened/read.  Instead, one could just look
at the file name.  It sounds like that would be more efficient indeed,
and require one less file to be opened.

Otis

--- Doug Cutting <[EMAIL PROTECTED]> wrote:
> Maybe I'm misunderstanding your proposal, but the problem is that the
> 
> resolution of file timestamps is not high enough.  On MacOS, HFS
> files 
> only have 1-second resoution, so one can't use a file's timestamp for
> 
> versioning unless one is willing to wait a second when checking the 
> version, which slows lots of things down.  So we're forced to either
> (a) 
> use the timestamp to represent a version, rather than a time, or (b) 
> implement a version or timestamp of our own, contained in a file. 
> Perhaps there are other options...
> 
> Doug
> 
> Hani Suleiman wrote:
> > Adding it inside of a file (segments or otherwise) would mean that
> the 
> > file has to be opened to be read...I might be completely wrong
> here, but 
> > wouldn't it be more efficient to have a separate timestamp file, eg
> 
> > something called segments.[timestamp], with appropriate magic to
> ensure 
> > it's atomically modified etc, and a filter to check for it?
> > 
> > Doug Cutting wrote:
> > 
> >> Christoph Goller wrote:
> >>
> >>> What about living the file timestamps as they are and using
> >>> an additional file per index that contains nothing but a counter 
> >>> (type long)
> >>> which gets incremented everytime the index is changed
> (SegmentReader and
> >>> IndexWriter). I could implement this.
> >>
> >>
> >>
> >> I think this is a good idea and would love to see an
> implementation.  
> >> My guess is that you would do something like add a file called 
> >> "version" which contains nothing but this long.  Alternately, you 
> >> could add the version at the end of the "segments" file or
> something.  
> >> Then all of the IndexReader lastModified methods could be changed
> to 
> >> return the value of the version rather than a date.  For 
> >> back-compatibility, the version could in fact be the millisecond
> time.
> >>
> >> Is that the sort of thing you're thinking of?
> >>
> >> Doug
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> 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]
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

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

Reply via email to