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: lucene-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
|