Great, moving forward fast on pristine design questions!
The one thing left now is:
> Can someone explain a motivation for even creating a database row before
> the pristine file is moved into place in the pristine store? I currently
> don't see why it can't be way simpler.
>
> (And, if it is necessary, how does a client deal with encountering a
> pristine table row that has a SIZE==null? Idle a bit and try to wait for
> the hypothetical other client process to finish? Discard and start
> fetching the pristine, possibly again?)
We will only write/store to the pristine tempdir and then move into place.
There will be no state "busy writing". Is there a different motivation left
for the special case SIZE==null?
The rest of the relevant stuff reposted below.
~Neels
Neels J Hofmeyr wrote:
> Greg Stein wrote:
>> The schema is designed to *allow* for faulty files. The faulty file
>> will NOT be used because SIZE==null in the database.
>>
>> If the file is successfully written, *then* we store a value into
>> SIZE, indicating the file is present and correct.
>>
>> Of course, if you're overwriting a pristine file, then you better
>> store SIZE==null before you begin writing.
>
> stsp and I have been discussing this a bit. I can't really see why
> indicating a null size in the PRISTINE table is necessary. Our discussion
> ended here:
>
> If we always write (copy) a pristine to a tempfile in the pristine tempdir
> first and then move it into the final pristine file location, there either
> *is* a complete pristine file, or there *isn't* one at all. (assuming atomic
> 'mv' within the same filesystem device. *can that be assumed??*)
>
> It's not difficult to prevent one client from wanting to install the same
> pristine twice within the same code path.
>
> To prevent two concurrently running clients from installing the same
> pristine twice, a file lock seems more appropriate (with one wc.db per WC,
> benefit of even that is debatable, but with one wc.db per user that might be
> good).
>
> Either way, a pristine can only have one specific content -- it does not
> really matter that much if one client overwrites it just after the other
> created it.
Received on 2010-02-18 03:01:45 CET