On Tue, Oct 13, 2009 at 11:38, Philip Martin <philip_at_codematters.co.uk> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>
>> Author: gstein
>> Date: Mon Oct 12 22:42:24 2009
>> New Revision: 39975
>>
>> Log:
>> Get rid of the "rerun" concept. Every operation should be able to be run
>> multiple times, and it shouldn't matter whether it is the FIRST or an
>> additional run.
>
> That's the theory but does it work in practice? How would I check?
> This revision and r37254 have removed the debug code that demonstrated
> how badly rerunning worked--there were loads of regression test
> failures last time I tried it.
It could very well fail in practice, but all these loggy operations
are going to disappear in favor of wc_db functions and/or workqueue
operations. As they get shifted, then we'll ensure they can be re-run
(which I did with the killme op).
The log_do_modify_entry code was a perfect example of this brokenness.
If I removed the test for ->rerun, then a lot of stuff broke because
the loggy function was used to create an entry, so yah: it was missing
and the function would exit. But if the intent was to create an entry,
then it should still do that on a rerun. The Proper solution would be
a create operation, and a modify operation. But I'm not going there,
in favor of just fixing it as part of the workqueue migration, and as
part of the migration away from entry_t and the "modify/create entry"
concepts.
Though it is a fair question to ask how we *ensure* and debug/test that.
We can "easily" test running a given workqueue operation multiple
times. It won't really be easy/possible to test a given operation
failing partway through, however.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407195
Received on 2009-10-13 22:57:52 CEST