On 08/01/2011 04:17 PM, Stefan Sperling wrote:
> On Mon, Aug 01, 2011 at 03:04:38PM +0200, Neels J Hofmeyr wrote:
>> - but on moves and reverts, the op_depth==0 row needs to be updated. So
>> - the op_depth==0 rows' moved-to columns can be corrupted by interrupted
>> operations. Yet this is easily remedied by a revert, clearing that column.
>
> Not sure what you mean here. In what way could columns become corrupted?
>
> Interruptions only happen on a higher level than individual column updates.
> We wrap most (all?) operations that run multiple statements in sqlite
> transactions -- see the various *_txn() functions in wc_db.c.
> Either all SQL statements in such functions fail or they all succeed.
Of course. Forget that point of mine.
>
> So if an op_depth==0 row has a non-NULL moved-to relpath column
> the relpath was inserted by a successful operation.
>
>>> Also, clear moved-to relpaths from the BASE tree during 'revert' so
>>> we don't leave phantom moved-to information in the DB (are there any
>>> other places where we need to clear it?).
>>
>> ^ here would be the remedy to any interrupted operations involving moved-to.
>> And at the same time this update of op_depth==0 rows during revert was not
>> necessary before this patch.
>
> It wasn't necessary because it was cleared by the existing revert code.
We had to add to the recursive revert code AFAIR
> I.e. this part of the required maintenance happened to be performed by
> existing code. But that doesn't mean less maintenance. We need to maintain
> moved-to data either way. I think it is easier to manage it in op_depth==0.
>
> Because of the transactional nature of our DB operations there are
> only two kinds of inconsistencies we have to worry about, at a fairly
> high level:
so true.
So pretty much my only concern is: do we want to avoid modifying the
op_depth==0 nodes?
~Neels
Received on 2011-08-01 18:56:48 CEST